Runs in your browser. Your files and text never leave your device - nothing is uploaded.
4xx Client Error
What it means
The request conflicts with the current state of the target resource.
| Property | Detail |
|---|---|
| Status class | 4xx Client Error |
| Defined in | RFC 9110, Section 15.5.10 |
| Cacheable by default | Only with explicit caching headers: a cache stores it when the response carries Cache-Control (max-age, s-maxage or public) or Expires. |
| Who needs to act | The client or user, who has to resolve the conflict before resubmitting. |
What does HTTP 409 Conflict mean?
HTTP 409 Conflict means the request could not be completed because it clashes with the current state of the target resource. Common examples are creating a record that already exists, or saving an edit based on an outdated version. The user can usually resolve the conflict and resubmit, and the response body should explain what clashed.
How 409 Conflict works
RFC 9110 reserves 409 for conflicts the user might be able to resolve, and says they are most likely in response to PUT. Its example is versioning: if a PUT carries changes that collide with edits someone else made in the meantime, the server can answer 409 with enough detail to merge the differences. APIs also use it for uniqueness rules, such as a username or email that is already taken, and for actions on a resource in the wrong state, such as cancelling an order that has already shipped. Sending the identical request again will produce the same 409.
Example 409 request and response
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
{"email": "ana@example.com"}
HTTP/1.1 409 Conflict
Content-Type: application/json
{"error": "email_taken", "detail": "An account with this email already exists."}The request is valid on its own; it conflicts with data that already exists. Choosing another email, or signing in, resolves it.
What causes a 409 Conflict
- Creating a record with a unique value, such as an email address, that already exists.
- Saving a document that someone else changed after you loaded it.
- Acting on a resource in the wrong state, such as refunding an order that was never paid.
- WebDAV PUT or MKCOL requests whose parent collection does not exist.
How to fix a 409 Conflict
If you sent the request
- Read the body to see which value or version clashed.
- For edit conflicts, fetch the latest version, reapply your changes and resubmit.
- Do not retry the identical request in a loop; it will keep failing.
If you build the API
- Return a machine-readable reason, such as the conflicting field or the current version number.
- For concurrent edits, support ETag and If-Match, so clients detect stale updates up front and receive 412 Precondition Failed instead of overwriting each other.
Related status codes
- 412 Precondition Failed: A conditional header such as If-Match did not match, so the update was refused before it ran.
- 422 Unprocessable Entity: The data is invalid in itself, regardless of what else exists.
- 400 Bad Request: The request is malformed rather than conflicting.
Tools that help
- Text Compare shows the differences between your version and the current one before you merge.
Frequently asked questions
The request conflicts with the current state of the target resource.
Common in APIs when trying to create a resource that already exists, or updating a resource that changed since it was last fetched.
Re-fetch the current state of the resource and resolve the conflict (e.g. use a different identifier, or merge changes) before retrying.
Both are used. A 409 emphasises that the request clashes with existing data, while a 422 treats it as a validation failure. Pick one convention for the whole API and document it; clients care more about consistency than about the exact code.
Sources
Other 4xx Client Error codes
Reviewed by Raja Jahangir · Last reviewed: October 7, 2026