Idempotency Key
A client-generated identifier that lets a server recognise a retried request and return the original result instead of performing the action twice.
Required on any unsafe operation a client might retry, which after a timeout is every unsafe operation — because a client that times out cannot distinguish "the request never arrived" from "it succeeded and the response was lost".
The mechanics that make it correct, in order of how often they are got wrong. The key is generated by the client, per logical operation, and reused across retries of that operation — a key generated per HTTP attempt achieves nothing. The server stores the key with the result and returns the stored response on a repeat, rather than merely refusing the duplicate, since the client needs the outcome. The key and the effect must be persisted atomically, or a crash between them reintroduces the double execution. Concurrent requests with the same key need a lock or a unique constraint so one proceeds and the other waits or is rejected. And the stored key should be bound to the request payload, so a client reusing a key with different parameters gets an error rather than the wrong cached response.
Retention is a real decision: keys must be kept at least as long as the client might retry, commonly 24 hours or more, which makes this a table that grows and needs pruning.
The design encouragement: expose it on any endpoint that moves money, sends a message, provisions something or creates a record. It converts a class of duplicate-action incidents into a non-event.