Cybersecurity glossary
What is Idempotency?
Learn what idempotency means in APIs and distributed systems, which HTTP methods are idempotent, why retries need it, and how to design write operations that can be safely repeated.
Definition
Idempotency is the property that performing the same operation multiple times produces the same effect on server state as performing it once—so retries, timeouts, and duplicate submissions do not create unintended extra side effects.
Why idempotency matters
Distributed systems lie about completion. A client may never see the 201 that the server already stored. Payment providers, inventory counters, and webhook handlers face the same dilemma: retry and risk duplicates, or give up and risk missing work.
Idempotency makes the safe choice possible. Retries become boring—and boring is what you want during incidents.
Idempotent vs safe vs non-idempotent
| Property | Means | Example |
|---|---|---|
| Safe | No server state change intended | GET /prices |
| Idempotent | Same effect whether called once or N times | PUT /profile with the same body |
| Non-idempotent | Each call may add another effect | POST /charges that creates a new payment each time |
DELETE is idempotent in the HTTP sense when deleting an already-deleted resource remains a consistent outcome (often 404 or 204). Incrementing a counter with POST is not.
How idempotent design works in practice
Identify side effects that must not duplicate
Charges, emails, inventory decrements, ticket creations, and provisioning steps are usual candidates.
Choose a natural or synthetic identity
Use a stable resource ID (PUT) or an idempotency key for POST-style actions.
Record the first successful application
Persist the outcome under that identity before acknowledging success to the client.
Detect retries
On duplicate submission, return the original result instead of applying the effect again.
Handle concurrency
Use transactions or conditional writes so two in-flight duplicates cannot both commit.
Document retry guidance
Tell clients which statuses are retryable and how long keys remain valid.
Where teams need idempotency most
Payments and billing
Timeouts during capture must not create double charges.
Webhook receivers
Providers redeliver events; handlers must ignore duplicates safely.
Provisioning APIs
Creating VMs, domains, or tenants twice can be costly and messy.
User-facing forms
Double-clicks and flaky mobile networks resubmit the same intent.
Security and integrity angles
Idempotency is not only reliability—it prevents some fraud and abuse patterns.
Replay without amplification
Attackers replaying captured requests should not multiply privileged side effects.
Authorization still required
Returning a cached idempotent result must still respect the caller’s permissions.
Key scoping
Idempotency identities must be bound to tenant/user so one client cannot reuse another’s key outcome.
Conflict detection
Same key with a different body should fail loudly (often 409), not silently apply the wrong effect.
Practical checklist
- List every externally visible write that money, inventory, or notifications depend on.
- Prefer naturally idempotent designs (PUT/DELETE with stable IDs) where the domain allows.
- For POST actions, adopt idempotency keys with clear retention windows.
- Make duplicate detection concurrency-safe under load.
- Return the original status and body on safe retries when possible.
- Reject key reuse with mismatched payloads.
- Apply the same discipline to async workers and webhook consumers.
- Test timeout-and-retry scenarios in staging—not only happy-path single calls.
The practical takeaway
Idempotency means repeats do not multiply effects. In HTTP and distributed systems, it is how you survive retries without corrupting business state.
Design writes as if every success response might be lost on the way home. When that assumption holds, mobile networks, load balancers, and webhook redeliveries stop being existential threats.
Related security terms
Idempotency Key
A client-generated token used to make non-idempotent POSTs safely retryable.
HTTP Method
HTTP verbs carry conventional idempotency expectations such as GET and PUT.
HTTP Status Code
Clients use statuses to decide whether a retry is appropriate.
Race Condition
Concurrent duplicates can break naive idempotency implementations.
Webhook
Webhook deliveries are often at-least-once and demand idempotent handlers.
Frequently asked questions
What is idempotency in simple terms?
It means doing something twice does not change the result beyond doing it once—like setting a thermostat to 21°C repeatedly, not adding +1 each time.
Which HTTP methods are idempotent?
By convention, GET, HEAD, PUT, DELETE, OPTIONS, and TRACE are idempotent. POST and PATCH are not unless you design them that way.
Is idempotent the same as safe?
No. Safe methods should not change state. Idempotent methods may change state, but repeating them should not amplify the effect.
Why do APIs need idempotency?
Networks fail. Clients retry. Without idempotency, a timeout after a successful charge can create a second charge.
Does a 200 response guarantee the effect applied once?
No. The response can be lost after the server committed. Idempotency protects the state change under retry.
Is “exactly once” delivery realistic?
End-to-end exactly-once is hard. Most systems provide at-least-once delivery plus idempotent processing to achieve exactly-once effects.
How is idempotency different from an idempotency key?
Idempotency is the property. An idempotency key is a practical mechanism to achieve that property for otherwise non-idempotent operations.
References
Explore authoritative guidance and frameworks related to idempotency.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.