422 Unprocessable Content — HTTP Status Code

What 422 means

422 Unprocessable Content says: "I can read what you sent, and it is in a format I accept, but the content does not make sense." It is defined in RFC 9110, Section 15.5.21. The RFC is precise about where 422 sits: the content type is supported, so 415 would be wrong, and the syntax is correct, so the problem is with the meaning of the data.

Before RFC 9110, the code lived in the WebDAV specification under the name Unprocessable Entity. Frameworks and documentation still use both names; they mean the same thing.

When you see it

422 is an API code. You see it in response to POST, PUT or PATCH requests that carry a JSON, XML or form body. Rails, Laravel, FastAPI and many other frameworks and REST APIs return it for failed validation, usually with a body that lists each field and what was wrong with it. The origin application sends it, not a proxy or CDN.

It is rare on plain page loads. A GET request has no body to validate, so a 422 on a GET usually means an app is validating query parameters, or a form submission is being replayed incorrectly.

Common causes

• Required field missing from the JSON body.
• Wrong type or format, such as a string where a number is expected, or a date in the wrong format.
• Business rule violated, for example an end date before the start date, a duplicate username, or a quantity above stock.
• Field name mismatch between client and server after an API version change, so a renamed field arrives as unknown and the required one is missing.
• CSRF or session tokens in some frameworks. Rails, for example, has historically returned 422 for an invalid authenticity token on form posts, which looks like a validation error but is really a session problem.

How to fix it

1. Read the response body. Most APIs that return 422 explain which field failed and why. That message is the quickest path to the fix.
2. Compare the request with the API's schema or docs. Check field names, types, nesting and required fields for the exact API version you call.
3. Log the exact body you send. Serialization layers can drop null values, rename keys or change number formats.
4. For form submissions, check session cookies and CSRF tokens, especially behind caches that might serve a stale form.
5. If you run the API, return a consistent, machine-readable error format, and use 400 for unparseable bodies and 422 for invalid but parseable ones, so clients can tell them apart.

How to check it

Send a request with deliberately bad data and look at both the status and the body:

curl -s -w "\nHTTP %{http_code}\n" -X POST https://api.example.com/v1/users \
  -H "Content-Type: application/json" \
  -d '{"email": "not-an-email"}'

A validating API typically answers HTTP 422 with a JSON list of errors. Fix the fields one at a time and repeat until you get a 2xx.

What it means for uptime monitoring

PingRobot's checker sends a GET with the user agent PingRobot/1.0 (+https://pingrobot.io/bot), follows redirects, and treats the final response as up only if its status is 200–399. A 422 counts as down, and every failure is re-checked from a second region before alerting.

A 422 is almost never an availability problem. The application is running and doing its job: rejecting input. If a monitor sees 422, look at the monitor first. The URL may point at an endpoint that expects a body or required query parameters, which a GET check will never satisfy. Point the monitor at a public page or a dedicated health endpoint that returns 200 on GET instead. A 422 that suddenly appears on a URL that used to return 200, with no change to the monitor, can point to a deploy that tightened validation on query parameters.

Related codes

• 400 Bad Request – the request cannot be parsed at all.
• 409 Conflict – valid data that conflicts with the resource's current state.
• 415 Unsupported Media Type – the body's format is not accepted.
• 413 Content Too Large – the body is too big.
• 429 Too Many Requests – valid request, but too many of them.

Start monitoring free — 10 monitors, no credit card.