409 Conflict

The HTTP 409 Conflict status code is a client error returned by the server to indicate the request cannot be satisfied because the current resource state is incompatible with the operation. The response body contains information the client uses to resolve the conflict.

Table of Contents

Usage

When a 409 Conflict error arrives, the request is valid but cannot be completed due to a state mismatch. For example, the client replies to a post since deleted, and the target resource is no longer in a compatible state. The server returns this status to signal the conflict.

The client is expected to examine the message body to determine how to resolve the issue. In the case of replying to a deleted post, the client opts to abandon the request, undelete the former thread, or create a new thread quoting the former text. This action is entirely the responsibility of the client, following requirements or policies set by the server.

SEO impact

Search engines like Google do not index a URL returning a 409 status. Previously indexed URLs returning this status code are removed from search results.

Example

The client attempts to tag an existing blog post with "ID = 111" with a "like". The server responds to indicate the post has been frozen and no longer accepts replies or tags.

Request

POST /blog/update?postid=111&flag=like HTTP/1.1
Host: www.example.re

Response

HTTP/1.1 409 Conflict
Content-Type: text/html
Content-Length: 288

<html>
  <head>
    <title>Blog Entry Frozen</title>
  </head>
  <body>
    <p>This post has been marked read-only. To post
    a reply or tag, change the status and try
    again.</p>
  </body>
</html>

How to fix

A 409 Conflict means the request conflicts with the current state of the resource on the server.

  1. Fetch the current resource state before retrying. Send a GET request to retrieve the latest version. The resource state changed since the client last read the data. Compare the returned ETag or version field against the value held by the client.

  2. Use conditional headers to detect conflicts. Include If-Match with the current ETag value on PUT and PATCH requests. The server rejects the request when the ETag no longer matches, preventing blind overwrites. This pattern is called optimistic concurrency control.

    PUT /api/resource/42 HTTP/1.1
If-Match: "abc123"
Content-Type: application/json

{"name": "updated value"}

    The server responds with 409 when another client modified the resource between the GET and the PUT.

  3. Merge changes or implement conflict resolution logic. Compare the client's intended changes against the current server state. Apply a merge strategy: last-write-wins, field-level merge, or prompt the end user to resolve differences. APIs with a version or revision field in the payload require the client to include the current version number with the update request.

  4. Resolve duplicate resource conflicts. When creating a resource with POST or PUT, the server returns 409 if a resource with the same unique identifier already exists. Check for existing entries before creating and use an idempotency key to avoid duplicate creation on retries.

  5. Handle database-level conflicts. Application servers backed by a database return 409 when a unique constraint, foreign key constraint, or row-level lock prevents the operation. The response body often includes the specific constraint name. Resolve the underlying data conflict (duplicate key, missing parent record, concurrent transaction) before retrying.

  6. For version control systems, pull the latest version and reapply changes. Retrieve the newest revision, reconcile differences, and resubmit the update. Git-based APIs (GitHub, GitLab) return 409 when a push conflicts with upstream changes.

  7. Inspect the response body for conflict details. The server typically includes information explaining the mismatch: the conflicting field, the current value, or the expected version. Use this data to determine the correct resolution path.

  8. Implement retry logic with state refresh. For automated clients, build a retry loop: fetch the latest resource state, reapply the intended modification, and resubmit. Add exponential backoff to avoid overwhelming the server under high-concurrency conditions.

Code references

.NET

HttpStatusCode.Conflict

Rust

http::StatusCode::CONFLICT

Rails

:conflict

Go

http.StatusConflict

Symfony

Response::HTTP_CONFLICT

Python3.5+

http.HTTPStatus.CONFLICT

Java

java.net.HttpURLConnection.HTTP_CONFLICT

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_CONFLICT

Angular

@angular/common/http/HttpStatusCode.Conflict

Takeaway

The 409 Conflict status code is a client error indicating the resource is not in a state compatible with the request. The response contains information sufficient to rectify the problem and allow the request to be resubmitted.

See also

Last updated: March 4, 2026