400 vs 409: Bad Request vs Conflict
400 and 409 can look similar in logs, but they tell clients, crawlers, and API consumers different things.
| Aspect | HTTP 400 — Bad Request | HTTP 409 — Conflict |
|---|---|---|
| Definition | The server received a request it cannot parse or understand. This is a client-side error — the request itself is malformed. | Often seen in REST APIs when a PUT or POST violates a uniqueness constraint or tries to create a resource that already exists. |
| Plain-language summary | The server cannot parse or process the request because it is malformed. The error is always on the client side — the request itself is structurally invalid. Common causes include invalid JSON, missing required headers, malformed URL encoding, or a content type mismatch. | 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. |
| When to use | Return 400 when the request is syntactically invalid or unparseable. Use 422 when the request is syntactically valid but semantically invalid (valid JSON that violates business rules). Use 401 for missing/invalid authentication, 403 for insufficient permissions, 404 for unknown resources. | 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. |
| Client behavior | Do not retry automatically — the same malformed request will receive the same 400. Fix the request format and retry. API clients should surface the error to the developer with the response body details. | Do not auto-retry. Resolve the conflict (e.g., fetch the current state and re-apply changes) before retrying. |
| Caching behavior | Not cached. Error responses are generally not stored. | Not cached. |
| SEO / crawler impact | Search crawlers interpret 400 (client-errors) for indexation and link equity accordingly. | Search crawlers interpret 409 (client-errors) for indexation and link equity accordingly. |
| API / backend impact | API clients branching on 400 expect Bad Request semantics. | API clients branching on 409 expect Conflict semantics. |
| Safe to retry? | Only after fixing the underlying cause | Only after fixing the underlying cause |
Common real-world scenarios
When you see HTTP 400
In API logs, 400s indicate client-side integration bugs. Sudden spikes in 400s often correlate with: a bad client deployment sending malformed payloads, a frontend change that broke the request format, or an API schema change that old clients have not adopted. Monitor 400 rates per endpoint to detect client bugs early.
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.
Decision rule
Use 400 when the response should communicate bad request behavior; use 409 when conflict is the accurate protocol signal.
A frequent mistake is swapping 400 and 409 for convenience; that causes client retry bugs, incorrect cache signals, and misleading monitoring data.
Use 400 when the correct protocol signal is Bad Request. Use 409 when the correct signal is Conflict. Returning either code for the wrong reason breaks client expectations, cache behavior, and monitoring accuracy.
FAQ
What is the biggest difference between 400 and 409?
400 communicates Bad Request, while 409 communicates Conflict. Choosing the right one keeps clients and intermediaries predictable.
Do 400 and 409 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 400 instead of 409?
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 400 Bad Request — full guide · HTTP 409 Conflict — full guide · HTTP 409 status reference · All comparisons · HTTP 400 status reference