What is an Idempotent API?

HTTP method semantics give a starting point — GET, PUT, and DELETE are specified to be idempotent (a repeated PUT with the same body should leave the resource in the same state; a repeated DELETE of an already-deleted resource should be a no-op, not an error), while POST is traditionally not, since it's often used to create a new resource each time it's called. In practice, teams still need to design POST endpoints carefully for idempotency wherever a duplicate submission would cause a real problem, such as creating two orders or sending two payments. The standard technique is an idempotency key: the client generates a unique token per logical operation and sends it with the request; the server records which keys it has already processed and returns the original result for a repeat, instead of executing the operation again. This lets a client safely retry on timeout or connection drop without a human needing to manually check “did that actually go through” before trying again.