409 Conflict

409 Conflict means the request could not be completed because it collides with the current state of the target resource, most often a concurrent modification, a duplicate unique value, or a state transition the resource doesn't currently allow. RFC 9110 ties this specifically to the resource's state rather than the request's syntax, so unlike 400, the request itself is perfectly valid; it's just incompatible with what the server holds right now.

The classic case is optimistic concurrency control: a client fetches a resource, another client or process modifies it, and the first client's subsequent PUT or PATCH carries an If-Match header referencing the now-stale ETag, which the server rejects with 409 rather than silently overwriting the newer data, a so-called lost update. Duplicate-key inserts, creating a user with an email address that already exists, are another common source, as are workflow state machines rejecting an action that no longer applies, such as canceling an order that has already shipped.

Good API design uses the 409 response body to describe exactly what conflicted, ideally including the current server-side state, so the client can decide whether to merge, overwrite, or abandon its change rather than guessing. Retrying the identical request unchanged will simply produce the same conflict again, which is what distinguishes 409 from transient errors like 503 that are worth retrying as-is.