idempotency key pattern
Caller sends a unique key with each request. The server keeps a record of keys it has seen and treats a repeat as the original — so retries (network hiccups, client doubt) don't double-charge or double-create.
Caller sends a unique key with each request. The server keeps a record of keys it has seen and treats a repeat as the original — so retries (network hiccups, client doubt) don't double-charge or double-create.
symptoms
- duplicate records / charges from retries
- ambiguous network failures with side effects
- unsafe retries blocking automation
causes
- non-idempotent endpoints (POST that creates)
- no dedup mechanism at the API boundary
fixes
- client supplies a UUID per logical action
- server stores key → response for some TTL
- return the original response on key-replay
you might say
- idempotency key
- use an idempotency token
- stripe-style idempotency