Idempotency-Key draft: 422 reuse vs Sume's 409 conflict
The IETF Idempotency-Key draft expired 18 April 2026 and uses 422 for a reused key; Sume returns 409 idempotency_conflict for a different body.
The draft says 422 when a key is reused with a different payload and 409 while a request is still outstanding. Sume's Errors page lists 409 for both cases, told apart by error code: idempotency_conflict for a different body and idempotency_key_in_use for a request in flight. The draft is not an RFC and its text says it expires on 18 April 2026.
Sources: the Internet-Draft and Sume's Errors page, read 2026-10-01.
What does the draft specify?
Its examples show 422 Unprocessable Content for a key reused across different payloads of an operation, and 409 Conflict with the title "A request is outstanding for this Idempotency-Key". It notes that clients should correct the request before retrying, except for 409 where no correction is required.
What does Sume return?
| Situation | IETF draft | Sume |
|---|---|---|
| Same key, different body | 422 | 409 idempotency_conflict: "already used with a different body" |
| Same key, request in flight | 409 | 409 idempotency_key_in_use, retryable: true |
What should my client do on each?
On idempotency_conflict the docs say to fix your key derivation and not retry as is. On idempotency_key_in_use they say to wait about a second and resend. Branch on the error code, not only the status, as in idempotency conflict vs key in use.
When is a retry safe?
The docs say not to retry unsafe submit requests without an Idempotency-Key. With one, a safe retry reuses the same key and body.
Sources
Related posts
More in Developers
- IETF RateLimit-Policy draft vs Sume's ratelimit-* headers
The IETF RateLimit draft defines structured RateLimit-Policy and RateLimit fields. Sume sends plain ratelimit-limit, -remaining, -reset and retry-after.
- Inngest retries a failed step four times: key the Sume submit
Inngest's default is four retries after the first attempt, five in all, and side effects are not exactly-once. Give the Sume submit an Idempotency-Key.
- Inngest NonRetriableError and RetryAfterError for Sume errors
Map Sume HTTP errors to Inngest: NonRetriableError for 400, 401, 402 and 404, and RetryAfterError with the retry-after header on a 429.
- Instagram API 100 posts per 24 hours: size your bulk queue
Instagram limits API-published posts to 100 in a moving 24-hour period, checked at content_publishing_limit. A Sume bulk queue also tops out at 100 items.
Written by Sume