HTTP 409 Conflict

What HTTP 409 means

HTTP 409 Conflict means the server understood the request but cannot apply it because it contradicts the current state of the target resource. The classic example is an edit collision: two clients loaded the same document, both saved, and the second save would silently overwrite the first.

Unlike 400, the request itself is well-formed — resubmitting it unchanged may even succeed later. The response body should explain what conflicts so the client (or user) can resolve it and retry.

Common causes of 409 errors

• An edit collision: the resource was modified by someone else since the client last fetched it (often surfaced via ETag / If-Match).
• Creating a resource that already exists — duplicate username, email, slug or file name.
• A version mismatch in optimistic locking: the submitted version number is stale.
• Deleting or moving a resource that has dependents the server refuses to orphan.
• Concurrent workflow steps applied out of order (e.g. approving an already-cancelled order).

How to fix it as a developer

• Read the response body — a good API names the conflicting field or the expected current version.
• Re-fetch the resource, reapply your change on top of the fresh state, and resubmit.
• Use conditional requests (If-Match with ETags) so conflicts are detected reliably instead of overwriting data.
• For duplicate-creation conflicts, decide idempotency up front: return the existing resource, or 409 with a pointer to it.

Example response

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

{"error":"conflict","message":"document was modified by another user","current_version":42}

FAQ