Skip to main content
Set the Idempotency-Key header on any retried POST so a network hiccup never double-charges the team.
If the request reaches us, we record the response. If you retry with the same key within 24 hours, we replay the original response — same status, same body, same X-Request-Id — without re-running the work.
Beta status (2026-05-04): the Idempotency-Key header is accepted but enforcement is rolling out. During beta the server records keys but does not yet replay; behaviour is “best-effort safe retries”. Watch the Changelog.

When to use it

Any time the request mutates state and a retry could double-bill. In practice that is: GET, PATCH, and DELETE are already idempotent at the protocol level — Idempotency-Key is ignored.

Key format

  • Up to 255 characters.
  • We recommend a UUID v4 generated by your client per logical request, not per HTTP attempt. A retry uses the same key.
  • Scope: per team. Two teams using the same key string see independent records.

Mismatched bodies

If you replay a key with a different body, we 409:
The check is a sha256 of the canonical request body. The cure is a new key — pick one fresh UUID per logical request.

TTL

Records are kept 24 hours from first use, then garbage-collected. After that the key is reusable. In practice, generate fresh keys; reuse is for retries within a single workflow.

Combining with retries

Idempotency-Key and exponential backoff are complementary. The first makes the server safe to retry; the second decides when.

Webhooks: idempotency on the receiver

Your webhook receiver should be idempotent too. Use the Autousers-Event-Id header as the dedup key. See Retry & replay.