422 Unprocessable Content

The short version: Read the response body. A 422 almost always lists the fields that failed and the rules they broke, and frameworks like Laravel, Rails, and FastAPI return them in a structured errors object. Fix those values and resend. Check your Content-Type too, since sending the wrong one can make every required field appear to be missing.

Key takeaways

• 422 Unprocessable Content means the request was well-formed and the server understood it, but the contents failed a validation or business rule. The envelope was fine; what was inside it was not.
• This is the line between 422 and 400. A 400 means the server could not parse the request at all. A 422 means it parsed cleanly and then broke a rule, like valid JSON whose email field is not an email address.
• The status arrived as Unprocessable Entity in RFC 4918 for WebDAV and was renamed Unprocessable Content by RFC 9110 in 2022. Both names appear in the wild and mean the same thing.
• Almost every 422 carries the answer in its response body. Laravel, Rails, Symfony, and FastAPI all return field-level errors, so reading the body is usually faster than reading your own code.
• A 422 is deterministic. Resending the same payload produces the same result, so retry logic that treats it like a 5xx just adds load without ever succeeding.

Error type

HTTP 4xx client error

Whose side

Usually the request; sometimes a stricter rule than documented

Fix difficulty

Easy

Common cause

The request parsed but failed validation

What does 422 Unprocessable Content mean?

A 422 Unprocessable Content is an HTTP status code in the 4xx family, and it occupies a very specific place in the sequence of things a server does with a request. The syntax was valid, so parsing succeeded. The content type was one the server handles, so it knew how to read the body. It got as far as understanding the request completely, and only then refused, because the instructions inside could not be followed. RFC 9110 describes it as the server understanding the content type and the syntax being correct, but being unable to process the contained instructions. In everyday terms, that is validation: a required field is absent, a value is the wrong type, a string does not match the format the endpoint demands, or a business rule says no.

The code was introduced by RFC 4918 as part of WebDAV, under the name Unprocessable Entity, and RFC 9110 brought it into core HTTP in 2022 with the name Unprocessable Content. Both names are still printed by real tools, and they mean the same thing. Frameworks adopted it enthusiastically for validation failures, so Laravel, Rails, Symfony, and FastAPI all return 422 with a structured list of field errors, and FastAPI returns it for any failure of a Pydantic model, including path and query parameters rather than just the body. That convention is what makes the code so practical: the response nearly always names its own cause.

422

HTTP status code

4xx

Client-side error class

2022

Renamed to Unprocessable Content in RFC 9110

How the 422 Unprocessable Content error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

api.example.com

422

Unprocessable Content

The request was understood but could not be processed.

• 422 Unprocessable Content
• 422 Unprocessable Entity
• HTTP Error 422
• Error 422
• Unprocessable Entity
• 422 validation failed

422 vs 400, 409 and 415

These four all reject the request, but they disagree about which part of it was unacceptable.

Where the request failed, and which code says so

These codes mark four different stages of handling a request, from unreadable through to conflicting with the current state.

What causes 422 Unprocessable Content?

• A required field missing from the request body. This is the most common trigger and the one the response body is most likely to name outright.
• A value of the wrong type, such as a string where the schema expects an integer, or a null where the field is not nullable.
• A value in the right type but the wrong format: an address that is not a valid email, a date that does not match the expected pattern, or a string longer than the field permits.
• The wrong Content-Type header, so the server parses the body into an empty model and then reports every required field as missing, which looks far more alarming than it is.
• A query or path parameter failing validation rather than anything in the body, which is easy to overlook because attention naturally goes to the payload.
• A business rule rather than a schema rule: a quantity that exceeds available stock, a date range that ends before it starts, or a state transition the endpoint does not allow.
• A nested object or array shaped differently from what the endpoint expects, where the outer structure is valid and an inner one is not.

How to find the cause fast

1. Read the response body first. A 422 from any mainstream framework contains the field names and the failed rules, and that is usually the whole answer.
2. Confirm the Content-Type matches what you are actually sending. A JSON body announced as form data is a classic source of a 422 that lists every field as missing.
3. Send a minimal request containing only the required fields with known-good values. If that succeeds, add fields back until the 422 returns and you have isolated the offender.
4. Check the URL as well as the body, since path and query parameters are validated on many stacks and produce the same status code.

Terminal

curl -i -X POST https://api.example.com/users -d '{"email":"not-an-email"}'HTTP/1.1 422 Unprocessable Content{"errors":{"email":["must be a valid email address"]}}# the JSON parsed fine; the value inside it broke the rule

How 422 Unprocessable Content looks from the outside

A 422 is a normal HTTP response, so from outside the service looks entirely healthy: the connection opens, TLS completes, and a well-formed reply comes back fast. A basic up-or-down check will report the API up while every write is being rejected. The risk is sharpest after a deployment that tightens validation, because existing clients that were sending acceptable payloads yesterday start failing today, and nothing in the infrastructure looks wrong. Catching that needs a check that sends a realistic request to the endpoint and asserts the status code it expects, rather than one that only confirms the host answers.

To confirm the exact code a URL returns, or to re-test several at once after a fix, run them through the free bulk URL status checker.

How to fix 422 Unprocessable Content

If you are calling an API

1. Read the response body and fix the fields it names. This resolves the majority of 422s without any further investigation.
2. Verify the Content-Type header matches the body you are sending, usually application/json for a JSON payload.
3. Check every required field is present, correctly typed, and correctly formatted against the endpoint's documentation.
4. Inspect query and path parameters too, since many frameworks validate them through the same layer and report failures the same way.
5. Strip the request down to the minimum that should succeed, then add fields back one at a time until the error reappears.
6. Do not retry the same payload. A 422 is deterministic and will fail identically every time, so a retry loop only adds load.

If you run the API

1. Return field-level errors in the response body rather than a bare status code. A 422 that does not say what failed forces every caller to guess.
2. Keep the distinction with 400 honest: use 400 when the request could not be parsed and 422 when it parsed and then failed a rule. Mixing them makes both less useful.
3. Make sure your documented schema matches the validator that actually runs. A rule that is stricter than the documentation produces 422s that callers cannot diagnose.
4. Treat tightening validation as a breaking change. Clients sending previously acceptable payloads will start failing, and they will have no way to know why unless you tell them.
5. Log rejected payloads, with sensitive values redacted, so you can see whether a spike in 422s is one broken client or a rule that is too strict.

Still not fixed? Next steps

• Read the response body before anything else. Frameworks that return 422 nearly always include the field names and the rules they broke, which turns a vague failure into a specific one.
• Check the Content-Type you are sending. An endpoint expecting application/json that receives a form encoding may parse it into an empty model and report every required field as missing, which looks like a validation bug and is not.
• Compare the payload against the schema field by field: required fields present, types correct, formats valid, enums within range, and nested objects shaped as the endpoint expects.
• Remember that query and path parameters are validated too. A 422 with no obvious problem in the body often turns out to be a parameter in the URL failing a type or range constraint.
• If the payload looks correct and still fails, the rule may be genuinely server-side: a validator that is stricter than its documentation, or a business rule that changed. That is a fix for whoever owns the endpoint.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

A 422 that names its own cause

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

HTTP/1.1 422 Unprocessable Content
{"errors":{"email":["must be a valid email address"]}}

The wrong Content-Type makes every field look missing

# body is JSON but announced as form data
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d '{"name":"Ada"}'
# -> 422 listing name as required, because the body never parsed

Return 422 with field errors rather than a bare status

// the caller can act on this; a bare 422 leaves them guessing
http_response_code(422);
header("Content-Type: application/json");
echo json_encode([
  "errors" => ["email" => ["must be a valid email address"]],
]);

How to prevent 422 Unprocessable Content

The dangerous 422 is the one that starts after a deploy tightens validation, because every existing client fails at once while the service itself looks perfectly healthy from outside. Pulsetic checks your website and endpoints from multiple locations every 30 seconds and alerts you by email, SMS, voice call, Slack, Discord, Telegram, or webhook the moment a URL stops returning the status code you expect. It measures what a real client receives, so an endpoint that begins rejecting valid requests does not go unnoticed until the support tickets arrive.

Learn how Pulsetic's uptime monitoring detects this from the outside, across 15+ locations.

Sources and further reading

The specifications and vendor documentation this guide is written from, plus deeper reading on the parts it only summarises.

• MDN: 422 Unprocessable Content
• RFC 9110: HTTP Semantics (15.5.21 422 Unprocessable Content)
• RFC 4918: WebDAV, where the code was introduced
• RFC 9110: HTTP Semantics