Skip to main content

​
Choose the right recovery

The same error code describes two different situations. Check retryable before acting; HTTP status alone does not tell you whether to retry.

​
Different input

​
Request still processing

This example also has the HTTP response header Retry-After: 1.

​
Keep the retry identity stable

For operations that document idempotency, the key is scoped to the organization, service account, HTTP method, resource path and resolved API version. Changing any of those creates a different retry identity; it does not recover the original operation. Rotating a credential under the same service account does not change that identity, although the replacement credential must still have permission. Keep the original key, body, path and version when recovering from a timeout. Do not generate a fresh key merely to get past a conflict: the original write may already have succeeded. Retrieve the resource when its ID is known and use the operation’s documented recovery procedure. A completed replay carries Idempotent-Replayed: true where the operation documents response replay. Sending an Idempotency-Key does not make an operation idempotent unless its reference explicitly supports that header. Retry protection is bounded by the operation’s retention policy; it is not a permanent guarantee against duplicates. If processing remains unresolved, contact Living Security Support with the request_id, UTC timestamp, method, path and API version. Never include an API key, client secret or access token.