Idempotency and response loss

Persist a fresh operation identity and Idempotency-Key before a mutation that requires them. Retry only the same method, target and exact intended body. Many management operations also require a fresh UUIDv7 operation_id and current expected_version. These are distinct from the HTTP idempotency key; retain both. A successful replay returns durable nonsecret metadata. It never reveals a previously issued API key, root credential, callback token or approval link again. Save a first successful secret response into protected storage before continuing. If it is lost, use the documented independently authorized rotation or cancellation/recreation workflow. State compare-and-set is a revision contract rather than permission to overwrite. Event idempotency belongs to one inbox. Schedule run uniqueness belongs to the scheduled logical run. Webhook delivery remains at least once: receiver-side deduplication is still necessary. Receipts have bounded retention and authorization is always rechecked. An expired receipt cannot resurrect a deleted resource, an expired approval or revoked authority. Do not use retention expiry as a retry strategy.

Read this guide as Markdown · Check enabled capabilities · Human dashboard