422 Unprocessable Content: What It Means and How to Fix It

Applies to: REST APIs and web frameworks; tested with Laravel 13.34 on PHP 8.5

422 Unprocessable Content means the server understood the request (the format and content type are fine) but can’t process the data in it, most often because a value fails validation: a required field is missing, an email address is invalid, a date has the wrong format. RFC 9110 calls it “Unprocessable Content”; many servers still show the older name Unprocessable Entity (Apache does).

400 or 422?

• 400 Bad Request: the request itself is broken, for example invalid JSON or a malformed header (see 400 Bad Request).
• 422: the request is well-formed, but the values in it are not acceptable.

An example: Laravel validation

We sent a POST without an email address to a Laravel 13 route that requires one, with the header Accept: application/json:

HTTP/1.1 422 Unprocessable Content
{"message":"The email field is required.","errors":{"email":["The email field is required."]}}

With email=nope the body said The email field must be a valid email address. The same form posted from a browser (without the JSON header) got a 302 back to the form, with the errors stored for the page to show. So API clients see 422, browsers see the form again.

How to fix it when you call an API

1. Read the response body: it lists the fields and what is wrong with each.
2. Check required fields, formats (dates as 2026-09-29, valid email addresses) and types (a number, not "5" as text, if the API expects a number).
3. Send JSON with the right headers:

   curl -i -X POST https://api.example.com/subscribe \
     -H "Accept: application/json" \
     -H "Content-Type: application/json" \
     -d '{"email":"user@example.com"}'

4. In n8n or other automation tools, open the failed node and look at the full error response, not just the status code.

If you build the API

• Return one clear message per field, as in the example above.
• Log validation failures to see which clients send bad data.
• Document required fields and formats.

Official documentation: RFC 9110 (HTTP semantics, section 15.5.21).