How it works
Add anIdempotency-Key header with a unique value. A repeat of the same request with the same key within 24 hours returns the original response without re-executing the operation.
{ idempotencyKey } as its trailing options argument.
Key behaviours
Response headers
A response to a request that carried an idempotency key includes:
When a request fails with a transient error (5xx or
429), the response also includes:
Error handling
- 2xx — stored and replayed on retry
- 4xx (validation, not found, and so on) — stored and replayed; these outcomes are deterministic, so a retry with the same parameters would fail the same way
- 429 — not stored; the key is released so you can retry after backing off
- 5xx — not stored; the key is released so you can retry
Key format
- At most 255 characters
- Printable ASCII only
- Any scheme works; a short prefix plus a stable business identifier is easy to read in logs, for example
ik_signup_<user_id>or a UUID
Expiry
Keys expire 24 hours after first use. After that the same string can be used for a new operation.Which endpoints support it
Every mutating endpoint —POST, PUT, PATCH and DELETE — accepts Idempotency-Key. GET requests are idempotent by nature and ignore the header. The one exception is POST /events, which uses the per-event unique_id instead.
Related
- Errors — status codes, request IDs and which failures are safe to retry
- API overview — headers, versioning and base URLs
- Developer quick start — idempotent subscription creation in context