HTTP 422 — Unprocessable Content
HTTP 422 splits a fine hair after 400: the request is syntactically fine but semantically impossible — well-formed JSON describing something the business rules reject. WebDAV coined it; REST APIs adopted it for validation errors.
When 422 shows up
- Order payloads that parse cleanly but reference impossible quantities.
- Form submissions failing domain validation despite valid syntax.
Mocking a 422 response
A response with this status can be faked end to end with a local mock rule — no backend changes needed. The configuration below mirrors the rule fields the ApiSimul editor uses (method, path, status, delay in milliseconds, response body):
{
"method": "GET",
"path": "/api/orders",
"status": 422,
"delay": 230,
"enabled": true,
"body": {
"error": "unprocessable",
"issues": [{ "field": "quantity", "rule": "must be positive" }]
}
}Dynamic placeholders such as {{random.name}}, {{string.uuid}} or {{number.int 1 100}} can appear inside the body to vary each response, which keeps client-side list rendering and retry logic honest during development.
Frequently asked questions
What does HTTP 422 mean?
The request was understood but its content cannot be processed. The body should pinpoint the failing rules so the client can correct the data.
How can I test a 422 response without a real backend?
Define a mock rule with the method and path your client requests and set the status to 422. The example configuration above returns this response after the listed delay, so the client exercises its 422 handling exactly as it would against a live server.
Related status codes
Need the response in your own project? Spin up rules for any status with the ApiSimul mock server, or browse every status code page.