Lesson 20 / 25

Idempotency

Make retries safe with idempotent methods and Idempotency-Key headers, especially for payment-style operations.

Same result, no matter how many times

An operation is idempotent if calling it once has the same effect as calling it many times. PUT /orders/482 (replace with this exact body) and DELETE /orders/482 are idempotent — the resource ends up in the same state either way.

Why it matters for retries

Networks drop responses, not always requests — a client that times out doesn't know if the server actually processed it. If the operation is idempotent, retrying is always safe. POST (usually creates) is the classic non-idempotent case.

Making POST safe to retry

An Idempotency-Key header lets the client supply a unique id per logical operation; the server stores the result and replays it if the same key arrives again — common in payment APIs.

POST /payments HTTP/1.1
Idempotency-Key: 6c9a1e4e-3f21
Content-Type: application/json

{ "amount": 500, "currency": "INR" }

PATCH usually isn't idempotent

A PATCH like { "increment": 1 } gives a different result each time it's applied. Prefer PATCH bodies that set absolute values when idempotency matters.