Skip to main content
How-to guideApplies to: Unified engine deployments
Identify one intended operation with the identity field that API expects. Keep that identity and request content when recovering a lost response.

Know the identity field

The exact request schema decides which fields are supported. There is no universal Idempotency-Key request header for all engine APIs. Notification delivery has its own event identity.

Recover the same request

If a mutation returns a server error or its response is interrupted, the example keeps the exact prepared URL, method, headers, and body. Its example values are locked. For requests with a supported identity, Retry same request resends that exact request. A fresh ID can create new work. Read status using the original identity when possible. Open-session creation does not have a caller-supplied idempotency identity; inspect server state before creating another session after an uncertain response. A successful write is marked Sent to avoid starting the same work again by mistake. Start new work from your own client with a new identity. Leaving the page does not cancel or undo earlier work.

Handle revision conflicts

expected_revision protects a workload or document against a stale edit. Catalog mutations use their catalog revision contract. A conflict means you should read and review the current resource; it is not a signal to replace the revision silently and repeat a write. A selective rerun preserves an earlier invocation. A normal new run can use the current definition. See Workloads for execution semantics.
Last modified on November 4, 2026