HTTP 409 Conflict
HTTP 409 Conflict means the request cannot be completed because it would create a conflict with the current state of the target resource. The conflict is temporary and may be resolvable by the client — the request may succeed later or with different data.
Quick reference
| Code | 409 |
|---|---|
| Name | Conflict |
| Category | 4xx Client Errors |
| Specification | RFC 9110 §15.5.10 |
| IANA status | Assigned |
| Client behavior | Resolve the conflict — refresh the resource state, reconcile conflicting data, or change the request — and retry. |
| In-depth guide | HTTP 409 conflict resolution guide → |
What it means
409 is about state: the request is syntactically valid and the server understood it, but executing it would violate a consistency rule on the resource. RFC 9110 notes that conflicts are "most likely to occur in response to a PUT request" — for example, trying to upload a file that is checked out by another user, or trying to set a resource version number backward.
The key distinction from 400 Bad Request: a 400 means the request itself is malformed. A 409 means the request is correctly formed but the target resource's current state makes it impossible to execute. The response body should explain what the conflict is and ideally how to resolve it.
Optimistic concurrency control and ETags
One of the most common uses of 409 is in optimistic locking implementations. A client reads a resource and gets an ETag. It then sends a conditional update with If-Match: [etag]. If another client has modified the resource in the meantime, the ETag no longer matches and the server returns 409 (or 412 Precondition Failed). The client must re-fetch the latest state, merge its changes, and retry.
Common causes
Duplicate resource creation
Attempting to create a resource that already exists — a user registration with an email already in use, a collection item with a name that must be unique, a database record with a primary key conflict. The server returns 409 to signal uniqueness violation rather than silently overwriting.
Version or ETag conflict
An update request carries a version number or ETag that no longer matches the current resource state because another client modified it first. The client must obtain the current state and reconcile the conflict before re-submitting.
State machine violation
A resource can only transition between certain states. Attempting an invalid state transition — cancelling an order that is already shipped, approving a review that is already published — returns 409. The response body should specify what transitions are currently valid.
Dependent resource still exists
Deleting a parent resource that still has child records in a system that enforces referential integrity returns 409. The client must remove the children before deleting the parent.
409 vs 400 vs 422 vs 412
| Code | Problem type | Example |
|---|---|---|
| 409 | Conflict with current resource state | Username already taken, version conflict, state machine violation |
| 400 | Malformed request syntax | Invalid JSON, missing required field |
| 422 | Syntactically valid but semantically invalid | Age field is negative, date is in the past |
| 412 | Conditional request precondition not met | If-Match ETag does not match current resource |
See also: 400 vs 409 · 409 vs 412 · 409 vs 422
Related resources
On this site: HTTP 409 conflict resolution guide · HTTP 410 Gone · HTTP 412 Precondition Failed · HTTP 422 Unprocessable Content · HTTP 400 Bad Request · All 4xx client errors
Comparisons: 400 vs 409 · 409 vs 412 · 409 vs 422
Standards: RFC 9110 §15.5.10 · IANA Registry · MDN Web Docs: 409