4xx client errorFix the data, then retryLook for field errors

422 Unprocessable Content

The server understood the request and its syntax is fine, but the data in it can't be processed: a field fails validation or breaks a business rule. It started out in WebDAV as "Unprocessable Entity" and has been part of HTTP itself since RFC 9110.

Open JSON Schema Generator Generate a schema from a request that works.

Common causes

A required field is missing or has the wrong type: a number sent as a string, null where an object is expected.
A value is out of range or badly formatted: an email without @, a date in the wrong format, a negative quantity.
Fields contradict each other, such as an end date before the start date.
Some frameworks send it for every validation failure: FastAPI always, Laravel for JSON requests, and Rails scaffolds.

How to fix it

Read the error list in the body. FastAPI returns detail with a loc path per field; Laravel returns an errors object keyed by field name.
Map the errors back to the form fields instead of showing one generic message.
Compare the request with the API's schema. A JSON Schema generated from a request that works gives you something to check the failing one against.
Watch for values JSON can't carry exactly, such as 64-bit IDs that lose precision as JavaScript numbers.

422 or 400?

400 when the request can't be parsed, 422 when it parses but the content is wrong. If the same body would be accepted with different values, it is a 422.

Example

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

{
  "detail": [
    {
      "loc": ["body", "email"],
      "msg": "value is not a valid email address",
      "type": "value_error"
    }
  ]
}

Defined in RFC 9110, section 15.5.21.