422 vs 424: Unprocessable Content vs Failed Dependency
422 and 424 can look similar in logs, but they tell clients, crawlers, and API consumers different things.
| Aspect | HTTP 422 — Unprocessable Content | HTTP 424 — Failed Dependency |
|---|---|---|
| Definition | The server understands the Content-Type and the request is well-formed, but cannot process it due to semantic errors. Common in REST API validation failures. | Failed Dependency describes how the server processed the request and what the client should do next. |
| Plain-language summary | The request body is syntactically valid (it parsed successfully) but semantically invalid — the content violates business rules or data constraints. The most common use is REST API field validation failures. | HTTP 424 Failed Dependency indicates a client errors response outcome. |
| When to use | Return 422 when the body was parsed correctly but failed validation: required field present but empty, value out of allowed range, date in the past when future is required, or custom business rule violation. Use 400 for parsing failures (malformed JSON, wrong Content-Type). Use 409 for conflicts with existing resource state. | HTTP 424 Failed Dependency indicates a client errors response outcome. |
| Client behavior | Do not auto-retry. Fix the payload based on the validation errors in the response body. Implement client-side validation to prevent 422s before the request is sent. | Client handles 424 according to client-errors semantics. |
| Caching behavior | Not cached. | See 424 caching spec. |
| SEO / crawler impact | Search crawlers interpret 422 (client-errors) for indexation and link equity accordingly. | Search crawlers interpret 424 (client-errors) for indexation and link equity accordingly. |
| API / backend impact | API clients branching on 422 expect Unprocessable Content semantics. | API clients branching on 424 expect Failed Dependency semantics. |
| Safe to retry? | Only after fixing the underlying cause | Only after fixing the underlying cause |
Common real-world scenarios
When you see HTTP 422
In form-heavy APIs, high 422 rates indicate: poor client-side validation that lets invalid data reach the server, mismatch between frontend and backend validation rules, or an API schema change that old clients have not adopted.
When you see HTTP 424
424 appears in production when: Malformed request format; Authentication or authorization mismatch.
Decision rule
Use 422 when the response should communicate unprocessable content behavior; use 424 when failed dependency is the accurate protocol signal.
A frequent mistake is swapping 422 and 424 for convenience; that causes client retry bugs, incorrect cache signals, and misleading monitoring data.
Use 422 when the correct protocol signal is Unprocessable Content. Use 424 when the correct signal is Failed Dependency. Returning either code for the wrong reason breaks client expectations, cache behavior, and monitoring accuracy.
FAQ
What is the biggest difference between 422 and 424?
422 communicates Unprocessable Content, while 424 communicates Failed Dependency. Choosing the right one keeps clients and intermediaries predictable.
Do 422 and 424 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 422 instead of 424?
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 422 Unprocessable Content — full guide · HTTP 424 Failed Dependency — full guide · All comparisons · HTTP 422 status reference · HTTP 424 status reference