HTTP 422 Unprocessable Entity
HTTP 422 Unprocessable Entity (originally from WebDAV, RFC 4918, and listed in the IANA registry) means the server understood the request's content type and syntax but cannot process the contained instructions due to semantic errors — for example a valid JSON body that fails business-rule validation. It is widely used by APIs to signal validation failures, sitting between syntactic 400 and successful processing.
What 422 means
422 Unprocessable Entity originated in WebDAV (RFC 4918) and is recorded in the IANA HTTP status code registry. It signals that the server understood the content type and the syntax was valid, but it cannot process the contained instructions because of semantic errors.
The canonical example is a request body that is well-formed JSON yet violates the resource's rules — a missing required field, an out-of-range value, or a value that fails a uniqueness check.
422 versus 400 and good API design
The practical distinction is syntactic versus semantic. 400 Bad Request covers requests the server cannot parse at all — malformed JSON, bad framing. 422 covers requests that parse cleanly but fail validation. Many frameworks adopt 422 for form and API validation so clients can tell 'I sent garbage' from 'I sent valid data that broke a rule'.
Good practice is to return a structured body listing which fields failed and why, so the client can fix the input precisely rather than guessing.
- 422 = syntactically valid but semantically invalid
- 400 = the server could not parse the request at all
- Return field-level validation detail with a 422
How it appears in analytics and logs
A 422 means the request parsed fine but failed validation rules. It is an API/write-path signal about input semantics, not about page indexability. Crawlers fetching pages do not normally encounter it.
Diagnostic use case
Recognise 422 on API endpoints as a semantic validation failure (not a malformed request), and return field-level error detail so clients can correct the input.
What WebmasterID can help detect
WebmasterID surfaces status codes for traffic, helping you distinguish semantic validation failures (422) on form/API endpoints from the page crawling that affects search visibility.
Common mistakes
- Returning 400 for validation failures, hiding the parse-vs-validate distinction from clients.
- Sending a bare 422 with no body explaining which fields failed.
- Assuming 422 affects page indexing — it is an API/form validation signal.
Privacy and accuracy notes
A 422 is a validation-outcome status with no inherent personal data. WebmasterID records the status without storing the submitted field values.
Frequently asked questions
- When should an API return 422 instead of 400?
- Use 400 when the request cannot be parsed (malformed syntax) and 422 when it parses correctly but fails semantic validation, such as a missing required field or an invalid value.
Related pages
- HTTP 400 Bad Request for crawlers
400 Bad Request means the server refused to process the request because it appeared malformed — bad syntax, invalid headers, or a request the server cannot interpret. Seeing 400s for crawlers usually points at malformed URLs, encoding issues, or a misbehaving edge layer rather than the crawler itself.
- HTTP 415 Unsupported Media Type
HTTP 415 Unsupported Media Type is returned when the origin refuses a request because its payload is in a format the target resource does not support — for example sending XML to an endpoint that only accepts JSON, or omitting the Content-Type header. It is a request-format error on the write path, so read-only page crawling does not normally produce it.
- HTTP 409 Conflict
409 Conflict means the request could not be completed because it conflicts with the current state of the target resource — for example a concurrent edit or a version mismatch. It arises in write and API workflows, not in the GET fetches crawlers issue, so a 409 in crawler logs usually points at an action endpoint being reached.
- Website observability
Separate API validation failures from page-crawl status codes, recorded server-side.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.