Act reliability - Darwin

Act is durable. Your client should be able to restart, lose a network response, or close a browser interaction without losing the authoritative state.

Make mutations idempotent

Every Start, Update, Approve, and Stop mutation requires a stable requestId. If the response is lost, retry the identical request with the same ID. Do not create a new ID until the logical mutation changes.

Recover from the action ID

Persist actionId before rendering the next screen. After a timeout or client restart, call Get action. Do not start a replacement Action merely because the previous response was delayed.

Retry by status

Response	Recovery
`409`	Read the current Action; the mutation may conflict with its latest state or replay record.
`429`	Respect `Retry-After`, then retry with backoff and the same `requestId`.
`503`	Retry with exponential backoff and jitter.
`401`	Refresh or replace the Darwin credential.
`403`	Request the required scope or authority; blind retrying will not help.
`404`	Verify the Action ID and authenticated owner context.

Monitor without leaking secrets

Record operation, latency, status, actionId, requestId, and Darwin’s response correlation ID. Do not log API keys, OAuth tokens, provider credentials, payment data, or unredacted sensitive inputs. See Rate limits and Errors for shared transport behavior.