HTTP 422 Unprocessable Content

The syntax is fine and the server understood the request, but the content is semantically wrong — a valid date in the past where a future one is required, a transfer that would overdraw an account.

Defined in RFC 9110 §15.5.21 — 422 Unprocessable Content · MDN reference

Defined for WebDAV in RFC 4918 §11.2 as "Unprocessable Entity", then generalised and renamed by RFC 9110.

Where you meet HTTP 422 in production

Validation failures: an email that is not an email, an end date before a start date, a quantity of zero on an order line, a field that is fine in isolation and wrong in context.

Why you would test it

The distinction from 400 is the point: 400 means "I could not read this", 422 means "I read it, and no". Clients should surface them to users differently.

What your client should do about a 422

Do not retry. Map the per-field errors onto the form the user is looking at — this is the one error class where the API can tell the client exactly what to fix, and a client that flattens it to "invalid input" throws that away.

422 versus the codes it gets confused with

Endpoints that return 422

23 endpoints in this playground answer with 422. Every one is free, needs no signup, and can be called from the browser or with curl.

Questions about HTTP 422

Is 422 only for WebDAV?
It originated there (RFC 4918) but is now standard in RFC 9110 and used widely for validation across REST APIs.
What should a 422 body look like?
A list of field-level errors: which field, what rule, and what was received.

Other client error codes

All HTTP status codes · All 39 mock REST APIs · Getting started guide

Last updated