What is idempotency in an API?
An operation is idempotent if doing it once or many times gives the same result. In APIs this matters because networks fail and clients retry. If DELETE /users/42 is idempotent, calling it twice still just leaves the user deleted, with no harm done. GET, PUT, and DELETE are idempotent, but POST usually is not.
- An idempotent operation gives the same result whether called once or many times.
- GET, PUT, and DELETE are idempotent, while POST is not.
- Idempotency lets clients safely retry requests after a network failure.
Why it is useful
Imagine a payment request times out. The client is not sure if it worked, so it retries. If the endpoint is idempotent, the retry will not charge the user twice. This is why safe retries depend on idempotency.
- GET: idempotent, reading many times changes nothing.
- PUT: idempotent, replacing with the same data repeatedly gives the same state.
- DELETE: idempotent, the resource stays deleted.
- POST: not idempotent, each call can create a new resource.
Mention idempotency keys for POST. Saying you can make create endpoints safe by having the client send a unique key that the server checks shows practical, senior level thinking.
Frequently asked questions
Why does idempotency matter for retries?
If a response is lost, the client can retry safely without causing duplicate changes, because repeating an idempotent request has no extra effect.
How do you make POST idempotent?
Use an idempotency key that the client sends with the request, so the server recognises a repeat and returns the original result instead of acting again.
Common follow up questions
Related interview questions
Want the full API Design guide?
Read every API Design concept with notes, diagrams, and code in one place. Track your progress as you go.
Open the API Design guide All API Design questions