Idempotency Key
A unique ID you attach to a request so retrying it does nothing the second time. The reason a retried payment doesn't charge twice.
See it
What it is
You generate a random ID (a UUID is fine) for one logical operation and send it with the request, usually in an 'Idempotency-Key' header. The server records the key alongside the result. If that key ever shows up again it skips the work and replays the stored response. Stripe popularized the header, and most payment, messaging, and ledger APIs now copy it.
Reach for it on any write with a real world effect: charges, refunds, orders, outbound emails and texts. GET, PUT, and DELETE are already idempotent by definition; POST is the one that needs help. The same idea protects you on the receiving end: webhooks and queues promise at-least-once delivery, so store the event ID and ignore repeats.
The mistake that undoes the whole thing: generating a fresh key on each retry. The key belongs to the operation, not the attempt, so create it once (ideally in the client, before the first send) and reuse it for every retry of that same intent. Also note keys expire (24 hours at Stripe), and a well built API rejects a reused key with a different body instead of quietly returning the old answer.
Ask AI for it
Make this POST endpoint idempotent. Accept an 'Idempotency-Key' header, store the key with a hash of the request body plus the eventual response status and payload in a table with a unique index on the key, and on a repeat key return the stored response without re-running the operation. Return a 409 if the same key arrives with a different body, expire records after 24 hours, and handle two concurrent requests with the same key safely. On the client, generate the UUID once per user intent and reuse it across every retry.