The journal

Is HTTP DELETE idempotent?

A direct answer with practical guidance on retries, status codes, and where idempotency keys do or don’t apply.

By Stack & Method editorial team · 2026-10-25

Minimal editorial diagram of an HTTP DELETE sequence showing initial success then a repeated request ending with resource not found

Yes. HTTP DELETE is defined as idempotent: repeating the same DELETE request has the same intended effect on the target resource as making it once. Responses may differ across attempts (for example 204 or 200/202 first, then 404 once the resource is gone) and DELETE is not safe because it changes state. See MDN for the DELETE method and idempotency definition (MDN: DELETE, MDN: Idempotent).

What idempotent means for DELETE

In HTTP, idempotency is about effect, not identical responses. A method is idempotent when the intended effect on the server from many identical requests is the same as from one request. For DELETE, that effect is that the resource is removed. The first DELETE might return 204 or 200/202; later identical DELETEs often return 404 because there is nothing left to delete (MDN: Idempotent, MDN: DELETE).

Note: the semantics of sending a request body with DELETE are undefined, and some servers may reject such requests with 4xx. Avoid including a body with DELETE (MDN: DELETE).

Minimalist full frame diagram of an integration test flow showing create resource then delete then repeat delete with visual success and neutral indicators and a compact icon based event log

How idempotency keys fit in

Idempotency keys are mainly for making non-idempotent methods like POST and PATCH safe to retry. The non-standard Idempotency-Key request header lets a server detect and coalesce duplicate POST/PATCH attempts, commonly replaying the first response; servers may return 409 while a request with the same key is still processing, 422 if a reused key has a different payload, and 400 if a required key is missing (MDN: Idempotency-Key header).

You generally do not need idempotency keys for DELETE because DELETE is already idempotent by definition. Still, some teams choose to accept an idempotency key on DELETE to correlate retries or replay the first response consistently; if you do this, document the retention period and matching rules for keys (MDN: Idempotency-Key header).

Designing DELETE endpoints for clean retries

Server-side conventions

Return a clear success on first delete: 204 No Content is common; 200 OK with a body or 202 Accepted (for async deletions) are also valid (MDN: DELETE).
Document what a repeat delete returns. Many APIs return 404 Not Found once the resource is gone; some return 204 again; others use 410 Gone to signal a resource that used to exist but is now deleted (MDN: Idempotent, Retry-friendly idempotent delete).
Make the target deterministic. Endpoints like DELETE /carts/7/items/{itemId} are idempotent; designs like DELETE /carts/7/items/last are not, because each repeat can remove a different item (Idempotency in REST).

Client retry rules

It is safe to retry a DELETE after transient failures such as timeouts or connection drops, because DELETE is idempotent. Handle any of 204/200/202 as success on the first attempt (MDN: Idempotent, MDN: DELETE).
For retries, treat 404 Not Found (and, if your API uses it, 410 Gone) as terminal results meaning the resource is absent, provided no additional side effects must occur (MDN: Idempotent, Retry-friendly idempotent delete).
Use exponential backoff and avoid sending a request body with DELETE (MDN: DELETE).

Test your DELETE flow

For a disposable resource: create it, DELETE it once, then DELETE it again. Verify the first call returns a documented success (204/200/202), the second returns your documented repeat result (often 404 or 204), and that no additional downstream side effects fire twice. Different status codes across attempts are compatible with idempotency as long as state does not change further (MDN: Idempotent).

Minimalist vector checklist for engineers showing icons for confirm docs, disposable resource tests, observe side effects, record acceptable status codes

Common pitfalls

Equating idempotent with safe. DELETE is idempotent but not safe; it changes server state and can have side effects like cascaded deletions or notifications (MDN: Idempotent).
Relying on identical responses. A repeat DELETE may return 404 rather than the initial 204/200/202; design client logic around end state, not identical payloads (MDN: Idempotent).
Including a DELETE request body. Its semantics are undefined and some servers reject it (MDN: DELETE).

Verify DELETE is safely retryable for your endpoint

Check the API docs for DELETE semantics and documented repeat status codes (204/200/202 vs 404/410).
Run a create → delete → repeat delete test and confirm no further state change on repeat.
Decide and implement client handling: treat 404/410 as terminal success when your goal is resource absence.
Ensure the endpoint targets a specific resource (avoid designs like “delete last”).
If supporting Idempotency-Key on DELETE for consistency, document key TTL and 409/422 behaviors.

FAQ

Should clients treat 404 after a DELETE as success?

Often yes. If the objective is “make this resource absent,” a 404 on a repeat DELETE is consistent with idempotency and can be considered a terminal success for retries, as long as no required side effects are missing (MDN: Idempotent).

Do I need idempotency keys for DELETE?

Usually no. DELETE is already idempotent. Keys are most useful for POST/PATCH to avoid duplicates; some APIs still accept keys on DELETE for response replay or tracing (MDN: Idempotency-Key header).

What should a server return on a repeated DELETE?

Pick and document one approach: 204 No Content again, 404 Not Found if the resource is absent, or 410 Gone if it previously existed and has been deleted (MDN: DELETE, Retry-friendly idempotent delete).