Reference
Retries and Idempotency
How to make Atlas integrations retry-safe across writes, event-feed reads, and webhook delivery.
Atlas uses different retry-safety patterns for different integration paths.
Webhooks and event feeds
Webhook consumers and reconciliation jobs should de-duplicate by Atlas event id.
That is the primary idempotency key for the shared event envelope.
Write requests
Atlas does not expose a public Idempotency-Key contract on customer-facing write endpoints.
- do not assume Atlas stores request keys for replay safety
- do not expect
409responses to represent idempotency collisions - make retries from your own application using a stable internal operation record
What to do instead
Use the following approach in your integration:
- de-duplicate webhook events by Atlas event
id - persist your own request or job IDs for control-plane writes
- retry the same logical operation with the same internal record
- confirm final state after a timeout or transport failure instead of assuming the write failed
- treat duplicate create attempts as application-level conflicts, not Atlas idempotency responses