400 when the request could not be parsed at all; 422 when it parsed and failed validation. The distinction separates transport and serialisation problems from business-rule problems, which is worth having in your logs.

Is 422 a standard status code?

Yes. It came from WebDAV and is now part of the core HTTP semantics specification, where the reason phrase is 'Unprocessable Content'. GitHub, Stripe and Laravel all use it for validation errors.

How should I structure a 422 body?

List every failing field with a machine-readable code and a human-readable message, so a UI can highlight all of them at once. RFC 9457 problem+json gives you a standard envelope if you want one.

422 Unprocessable Entity

The request was well-formed but failed validation rules.

Class 4xx · Client error
Retry Do not retry

What 422 means

422 draws a distinction 400 cannot: the syntax is fine, the server parsed the body successfully, and the content is still not acceptable. An email field containing 'not-an-email', a quantity of -5, a date in the past where a future date is required - all parse, all fail validation.

That distinction is worth making because it separates two very different debugging paths. A 400 points at serialisation, encoding or transport; a 422 points at business rules. Collapsing both into 400 means every client-side failure looks the same in your logs.

It originated in WebDAV and is now standard for REST APIs - GitHub, Stripe and Laravel all use it for validation failures. Its value depends entirely on the response body listing which fields failed and why; a bare 422 is no more useful than a bare 400.

Note that the reason phrase was renamed to 'Unprocessable Content' in the current HTTP specification, though 'Unprocessable Entity' remains in wide use.

Common causes of a 422

A field failing a format rule - an invalid email, a malformed phone number, a bad URL.
A value outside an allowed range or not in an enum.
A business rule violation, such as an end date before a start date.
A required field present but empty.
A reference to a related entity that does not exist.
A JSON Schema validation failure where the document parsed correctly.

How to fix a 422

Return every failing field with its reason, not just the first - clients want to show all errors at once.
Use a consistent error shape across the API so clients can parse it generically.
Consider RFC 9457 problem+json for a standard structure.
Keep 400 for genuinely unparseable requests so the two remain distinguishable.

Should a client retry?

The content is invalid. Retrying unchanged fails identically - fix the data first.

FAQ

422 or 400?: 400 when the request could not be parsed at all; 422 when it parsed and failed validation. The distinction separates transport and serialisation problems from business-rule problems, which is worth having in your logs.
Is 422 a standard status code?: Yes. It came from WebDAV and is now part of the core HTTP semantics specification, where the reason phrase is 'Unprocessable Content'. GitHub, Stripe and Laravel all use it for validation errors.
How should I structure a 422 body?: List every failing field with a machine-readable code and a human-readable message, so a UI can highlight all of them at once. RFC 9457 problem+json gives you a standard envelope if you want one.

Often confused with

400 Bad Request The server could not understand the request - it is malformed.
409 Conflict The request conflicts with the current state of the resource.