Skip to main content
An idempotency key is a client-chosen string you send with a write request so that retrying it — after a timeout, a dropped connection or a 5xx — applies the operation at most once. Use it on every request that creates or changes money-bearing objects: subscriptions, invoices, credit grants, checkout sessions. The API stores the first response under the key and replays it for later requests carrying the same key.
POST /events does not use the Idempotency-Key header. Each event carries its own unique_id, which is enforced as a natural unique key — a resend with the same unique_id is dropped. See Send usage events.

How it works

Add an Idempotency-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.
Every mutating SDK method accepts { 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
See Errors for what each status means.

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
Scope keys to one operation: do not reuse a key across endpoints, and do not derive it from values that change between retries (such as the current time).

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.
  • 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