An idempotency key is a unique value the client generates for one logical operation and sends with the request, usually as an Idempotency-Key header. Generate it once, before the first attempt, and reuse it on every retry; a key minted inside the retry loop protects nothing. Where the operation has a natural identity, such as an event id or an invoice number, use that, because it still matches after the client crashes and restarts. The server stores the key with the status and body of the first response and, when the same key arrives again, returns that stored response instead of running the operation twice. It makes a retried POST, which RFC 9110, section 9.2.2 does not define as idempotent, safe to repeat.
In an FDE interview
Any retry added to a call with side effects raises it: charging a card, creating a ticket, forwarding an event to a partner API. Vercel’s public fde-challenge-backend spec, created in July 2026, has the service forward each valid event to a partner catalog API with the event id as the idempotency key, and treat 429 and 503 as transient with at most three attempts in total; the file does not itself say it is an interview. Source 1HTTP contractPublisherVercel (vercel-solutions on GitHub)Source typecompany website
A naive key table misses the cases that matter: a retry that arrives while the first request is still running (HTTP 409 in the expired IETF httpapi draft on the header), the same key sent with a different body (HTTP 422 in the same draft; Stripe’s idempotent requests return an error), whether a failed first attempt is stored or left retryable, and an expiry window longer than the client’s retry horizon. Scope the key per tenant and endpoint. If the side effect is a row in your own database, write it and the key record in one transaction. If it is a call to another service, no transaction covers it: claim the key first with an in-flight state, pass the key downstream so that service deduplicates too, then record the response. Then say what a crash between the call and the record does: the in-flight row times out, and the retry reaches the downstream service with the same key, not a new one.
The idempotency-key handler question makes you handle two identical requests arriving at once and a reused key with a different body.