Activity and history

History is a read-only record of product mutations. Use listOrderActivity, listProcessItemActivity, listRecentActivity, listCompletedActivity and getWeeklyActivity as applicable. Never POST or PATCH an activity row; perform the canonical task/item/order/configuration action instead.

Reads are newest-first by occurredAt with a deterministic, opaque tie order. Preserve the cursor and filters; do not reconstruct cursors from public IDs. Orders embed at most50 entries and expose activityNextCursor for the order-history endpoint. Global and weekly projections are bounded independently; see pagination.

A product action may create a resource event (creation, edits, lifecycle/workflow transitions, template application, division) and a separate API audit record. These are different records: a read, a preview, an idempotent replay or a rejected request must not be interpreted as a fresh product change. Some configuration actions update version/configuration without adding a resource-history row; history is not a complete database changefeed. Follow returned state/version and request ID rather than requiring one activity per HTTP call.

Public actor metadata is {type:session|api_key|unknown,id?,requestId?,operation?}. The ID is an opaque user/key identifier, never its secret; legacy events without attribution return unknown. Revocation does not rewrite historical attribution. Correlation IDs carry no authority; see request correlation.

Resource activities currently have no automatic age-based expiry. They remain until supported resource/workspace deletion removes them; process deletion can retain read-only snapshot/history according to its preview. This is not an indefinite-storage SLA. API operational audit events have a separate90-day maintenance policy and are not part of the public resource activity collection. Idempotency records expire after24hours and are not history. Export includes retained public resource history, not operational security logs.