422 Unprocessable Entity: what it means and how to fix it

What 422 Unprocessable Entity means

422 originated in WebDAV (RFC 4918) and was later adopted broadly by REST APIs as the standard response for semantic validation failures. RFC 9110 formally renamed the status text to 422 Unprocessable Content, dropping the WebDAV-specific "Entity" wording, though both names describe the identical status code and "Unprocessable Entity" remains the far more common label in framework defaults and API documentation. The distinction that matters is syntax versus semantics: the JSON parsed correctly, every required field type matches, and the request is well-formed by every structural rule, but a value inside it violates a business rule, such as an email address in the wrong format, a date in the past where a future date is required, or a field that references a record that does not exist.

How the error appears

A 422 almost never appears as a browser navigation error, since it is overwhelmingly an API response rather than something a link or form submission triggers directly; it shows up in a network tab, an error toast, or a failed test assertion. From the command line, the body of the response is where the useful detail lives:

curl -i -X POST https://api.example.com/v1/users   -H "Content-Type: application/json"   -d '{"email": "not-an-email", "age": -5}'

HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json

{"errors": {"email": ["is not a valid email"], "age": ["must be greater than 0"]}}

Most well-built APIs return a structured error body alongside 422, naming exactly which field failed and why, rather than leaving the caller to guess from the status code alone.

What causes a 422 Unprocessable Entity

• Validation errors in REST APIs. Rails applications commonly return 422 automatically when an ActiveRecord model fails validation on create or update. Laravel's form request validation returns 422 by default for failed rules. FastAPI, built on Pydantic, returns 422 whenever request data fails a Pydantic model's type or constraint checks, which is why it is one of the most frequently seen status codes in FastAPI projects specifically.
• A field with the right type but an invalid value. A string where a string was expected, but one that fails a format check, a length limit, or an allowed-values list.
• A reference to something that does not exist. A foreign key, user id, or slug in the request body that is syntactically fine but does not correspond to any real record.
• Business rules beyond simple field validation. A discount code that is syntactically valid but expired, or a quantity that is a valid integer but exceeds available stock.
• Missing a required field entirely. Depending on the framework, an absent required field can return 422 rather than 400, since the request parses fine, it just lacks a value the validation layer requires.

422 versus 400

The line is syntax versus semantics. 400 Bad Request means the server could not parse the request at all, for example malformed JSON or a body that is not valid by any structural rule. 422 means the request parsed without any trouble, and every field is the right type, but a value inside it fails a rule the application checks after parsing. In practice many APIs blur this distinction and use 400 for both cases, which is defensible but less precise; a client integrating against an API should read the response body rather than relying on the status code alone to know exactly what failed.

How to fix a 422 error

If you are a client calling an API

1. Read the response body, not just the status code. A well-built API's 422 response names the specific field and rule that failed, which tells you exactly what to correct without further guessing.
2. Check the field against the API's documented constraints such as format, length, and allowed values, since these are business rules the schema alone will not show you.
3. Treat 422 as a signal to fix the data, not retry the request unchanged. Retrying an unmodified request that failed validation will fail identically every time; a well-behaved client should surface the specific error to the user rather than silently retrying.

If you run the API

1. Always return a structured error body alongside 422, naming the field and the rule that failed, rather than a bare status code with no explanation.
2. Keep validation error messages specific and actionable, for example "email must be a valid address" rather than a generic "validation failed" that forces the caller to guess which of several fields was the problem.
3. Decide deliberately between 400 and 422 for your API and document the choice, so integrators can build reliable error handling instead of treating every 4xx the same way.
4. Log the validated-but-rejected payloads during development to catch cases where your own client code is sending data that consistently fails validation, which often points at a mismatch between the client and the API's actual rules.

How a client should handle a 422 response

A well-designed client treats 422 as fundamentally different from a 5xx error or a network failure: it means the server is healthy and working correctly, and the caller sent something the server will never accept as-is. The right response is to parse the error body, map each failed field back to the form or input that produced it, and show the user something actionable, not to retry with backoff the way you would for a timeout or a 503. Automated tests that exercise an API's validation layer should assert on the specific error body returned, not just the 422 status code, since that is what confirms the validation logic itself is correct.

How to prevent 422s from going unnoticed

A validation rule that changed unexpectedly, whether from a deploy, a third-party library update, or a schema migration, can quietly start rejecting requests that used to succeed. An HTTP check that submits a known-good payload and asserts on the expected status code catches that kind of regression immediately after a deploy. For APIs with more than one endpoint or a payload the status code alone cannot fully verify, API monitoring that also checks the response body confirms the validation logic itself, not just that the server is reachable.

Related errors

See 400 Bad Request for the request-could-not-parse case this guide contrasts against, the 4xx overview for the wider family, and 401 Unauthorized and 405 Method Not Allowed elsewhere in this batch.

Frequently asked questions

Is 422 Unprocessable Entity the same as 422 Unprocessable Content?

Yes. RFC 9110 renamed the reason phrase to Unprocessable Content, but it is the same status code with the same meaning; most frameworks and API docs still use the older Unprocessable Entity wording.

Why does my FastAPI app return 422 for a missing field?

FastAPI validates request data against your Pydantic models automatically, and a missing required field, or one with the wrong type, fails that validation and returns 422 with a body describing exactly which field and rule failed.

Should I retry a request that got a 422?

Only after changing the data that failed validation. Retrying the identical request will produce the identical 422 every time, since the server is correctly and consistently rejecting the same invalid input.

What is the difference between 422 and 400 in practice?

400 is for a request the server cannot parse at all. 422 is for a request that parses fine but contains a value that fails a validation or business rule. Many real-world APIs use 400 for both, so always check the documented convention for the specific API you are calling.

Can a 422 mean the server has a bug?

It can, if the validation rule itself is wrong, for example rejecting a genuinely valid email format. But a 422 by design means the server is working as intended and objecting to the data, so investigate the actual validation rule before assuming it is broken.