HTTP Status Codes
HTTP 409 Conflict
Conflict — the request clashes with the current state of the target resource
A 409 response signals that the server understood the request and its syntax was valid, but completing it would violate the current state of the target resource. The conflict is resolvable — the client can adjust the request or fetch fresh state and retry. This distinguishes 409 from 400 Bad Request, where the request itself is malformed, and from 422 Unprocessable Content, where the payload fails semantic validation.
Visual summary
A quick reference view of how HTTP 409 works: Two elements trying to occupy the same state or space, resulting in a collision.
What 409 Means
The shortest useful reading of this status code.
Conflict means the request clashes with the current state of the target resource.
This status falls into the 4xx class, indicating a client-side error outcome for the request.
Quick read
Conflict
the request clashes with the current state of the target resource
Technical Context
How this status behaves without turning the page into a repair guide.
Standard usage
The 409 status is most closely associated with PUT requests in versioned or concurrent systems. When a client fetches a resource, modifies it locally, and submits the change, the server compares the client version against the current stored version. If another client modified the resource in between, the server returns 409 rather than silently overwriting the first edit — a pattern known as optimistic concurrency control.
Technical nuance
Beyond version conflicts, 409 covers any situation where business logic or data integrity prevents the request from completing. Creating a user with a username that already exists, deleting a category that still has child items, or transitioning an order from completed back to pending all represent state conflicts where the request is syntactically correct but semantically incompatible with current data.
Implementation detail
The response body for a 409 ideally includes enough detail for the client to understand and resolve the conflict. For version mismatches, this means returning the current server-side version or ETag so the client can merge or reapply changes. For uniqueness violations, identifying which field caused the conflict helps the user choose a different value. Without this detail, the client can only retry blindly.
Related HTTP Codes
Nearby HTTP status codes help clarify how 409 differs inside the same response family.
409
Conflict
the request clashes with the current state of the target resource
400
Bad Request
the server cannot process the request because it is malformed
412
Precondition Failed
a conditional header did not match current resource state
428
Precondition Required
origin server requires the request to be conditional
Common Causes
Concurrent modification of the same resource by multiple clients
A common condition that triggers a 409 response when the web server evaluates the transaction.
Attempt to create a resource with a unique identifier that already exists
A common condition that triggers a 409 response when the web server evaluates the transaction.
Database unique constraint or foreign key violation during the request
A common condition that triggers a 409 response when the web server evaluates the transaction.
Optimistic locking version mismatch between client and server state
A common condition that triggers a 409 response when the web server evaluates the transaction.
Typical Scenarios
Two editors save changes to the same document simultaneously, and the second save conflicts with the first
A registration API receives a duplicate email address that violates a uniqueness constraint
A PUT request carries a stale version number, indicating another client modified the resource since it was fetched
What To Know
Resolving a 409 requires understanding which type of conflict occurred. For concurrent edit collisions, the client fetches the latest resource state, merges or re-applies its changes, and retries the request. For duplicate resource creation, the client chooses a different unique identifier. For state transition conflicts, the client verifies the resource current state before attempting the operation again. Implementing conditional request headers like If-Match with ETags prevents many 409 scenarios by failing earlier with a 412 Precondition Failed instead.
Frequently Asked Questions
Common interpretation questions about HTTP 409.
The server understood the request and its syntax was valid, but completing it would violate the current state of the target resource. The conflict is typically resolvable — the client can adjust the request based on the server response and resubmit.
A 412 is returned when a conditional request header like If-Match or If-Unmodified-Since fails — the client set an explicit precondition that was not met. A 409 covers broader state conflicts such as duplicate resources, concurrent edits, or business logic violations detected at the application level without conditional headers.
Use 422 when the payload itself is semantically invalid — a required field is missing or a value fails validation rules. Use 409 when the payload is valid but conflicts with existing server state, such as a duplicate unique key or a version mismatch. The distinction is about where the problem lies: the data format versus the resource state.
The client reads the response body for conflict details, fetches the latest resource state with a GET request, reconciles the differences, and retries the original operation with updated data. Blindly retrying without resolving the underlying conflict will produce another 409.