409 vs 412: Conflict vs Precondition Failed
409 and 412 can look similar in logs, but they tell clients, crawlers, and API consumers different things.
| Aspect | HTTP 409 — Conflict | HTTP 412 — Precondition Failed |
|---|---|---|
| Definition | Often seen in REST APIs when a PUT or POST violates a uniqueness constraint or tries to create a resource that already exists. | Precondition Failed describes how the server processed the request and what the client should do next. |
| Plain-language summary | The request conflicts with the current state of the resource. Most common in REST APIs when trying to create a resource that already exists, or when concurrent edits produce a version mismatch. The response body should explain what the conflict is. | HTTP 412 Precondition Failed indicates a client errors response outcome. |
| When to use | Return 409 when the request is syntactically valid but conflicts with an existing resource state — duplicate email, concurrent edit conflict, version mismatch. Use 422 for semantic validation failures unrelated to conflicts. Include enough detail in the response body for the client to resolve the conflict. | HTTP 412 Precondition Failed indicates a client errors response outcome. |
| Client behavior | Do not auto-retry. Resolve the conflict (e.g., fetch the current state and re-apply changes) before retrying. | Client handles 412 according to client-errors semantics. |
| Caching behavior | Not cached. | See 412 caching spec. |
| SEO / crawler impact | Search crawlers interpret 409 (client-errors) for indexation and link equity accordingly. | Search crawlers interpret 412 (client-errors) for indexation and link equity accordingly. |
| API / backend impact | API clients branching on 409 expect Conflict semantics. | API clients branching on 412 expect Precondition Failed semantics. |
| Safe to retry? | Only after fixing the underlying cause | Only after fixing the underlying cause |
Common real-world scenarios
When you see HTTP 409
Common in registration flows (duplicate email), collaborative editing (optimistic locking), and idempotency enforcement. Spikes in 409 indicate concurrency issues in the application layer.
When you see HTTP 412
412 appears in production when: Malformed request format; Authentication or authorization mismatch.
Decision rule
Use 409 when the response should communicate conflict behavior; use 412 when precondition failed is the accurate protocol signal.
A frequent mistake is swapping 409 and 412 for convenience; that causes client retry bugs, incorrect cache signals, and misleading monitoring data.
Use 409 when the correct protocol signal is Conflict. Use 412 when the correct signal is Precondition Failed. Returning either code for the wrong reason breaks client expectations, cache behavior, and monitoring accuracy.
FAQ
What is the biggest difference between 409 and 412?
409 communicates Conflict, while 412 communicates Precondition Failed. Choosing the right one keeps clients and intermediaries predictable.
Do 409 and 412 have SEO or caching impact?
Yes. Search engines and caches interpret status classes differently. Use each code according to its semantics to avoid accidental indexing, stale responses, or crawl inefficiency.
Can APIs safely return 409 instead of 412?
Only when it matches contract semantics. API clients often branch logic by exact code, so swapping them can break retries, auth handling, or user-facing errors.
Full guides
HTTP 409 Conflict — full guide · HTTP 409 status reference · HTTP 412 Precondition Failed — full guide · HTTP 412 status reference · All comparisons