Idempotency is a property of an operation where running it once or running it many times gives the same end result. Press the button twice by accident and nothing extra happens. The system lands in the same place either way.
A simple example is a lift call button. You press it once, or you jab it five times because you are impatient, and the lift still arrives exactly once. Now imagine a payment instead: a shaky connection makes your app retry a charge, and without idempotency the customer gets billed twice. With it, the second attempt is recognised as a duplicate and quietly ignored. This is why careful API design, especially for a REST API handling money or orders, leans on idempotency keys to make retries safe.
It is also a safety net for automation. When a webhook fires twice because of a network hiccup, an idempotent handler makes sure the order is only created once.
How it works under the hood is worth knowing. The client sends a unique key with the request, and the server stores the result the first time it sees that key. If the same key shows up again, the server skips the work and replays the saved response. This connects directly to good error handling: the safest way to recover from a timeout is to retry, and retrying is only safe when the action is idempotent. The trap is assuming an action is harmless to repeat when it actually creates something new each time.
At TopDevs we design payment and integration flows to be idempotent, so a flaky connection or an impatient click never turns into a duplicate charge or a doubled record.
