409 Conflict

What 409 means

The request is well-formed and authorised but cannot be applied: creating a user whose email already exists, updating a record someone else changed first, or deleting something that is still referenced.

Optimistic concurrency uses 409 (or 412 with preconditions) to tell the client to reload and try again.

Common causes

• Duplicate unique key on create.
• Stale version number or ETag on update.
• State machine violation, such as cancelling an already shipped order.

How to fix it

• Return which constraint failed so the client can resolve it.
• Clients: refetch the resource, merge, and retry; do not retry blindly.

What it looks like

A typical response:

HTTP/1.1 409 Conflict
Content-Type: application/json

{"error":"conflict","detail":"email already registered"}

The same event in an nginx access log (the status is the number after the request line):

203.0.113.7 - - [10/Sep/2026:10:12:01 +0000] "POST /api/orders HTTP/1.1" 409 153 "-" "Mozilla/5.0"

Check it with curl

-i prints the status line and headers, and -w '%{http_code}' prints only the number, which is handy in scripts and health checks. Replace the URL with yours:

curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' https://example.com/api/orders

Compare what curl sees with what the browser sees. A different status from the same URL usually means a cache, a CDN edge or a cookie is in the way.

Investigating a run of 409s? Paste the log excerpt into Log Share to get line numbers, highlighting and an expiring link for whoever is on call with you.

Related status codes

• 412Precondition Failed: an If-Match or If-Unmodified-Since condition was false.
• 422Unprocessable Content: The request is syntactically valid but semantically wrong.
• 201Created: The request created a new resource, identified by the Location header.

FAQ