HTTP 422 Unprocessable Entity — What It Means & How to Fix

HTTP 422 Unprocessable Entity is an HTTP response status code that indicates the server understands the request body’s content type and syntax but cannot process it due to semantic errors. It is the standard response for validation failures in REST APIs, form submissions, and data processing endpoints.

What It Means

Defined in RFC 4918 Section 11.2 (WebDAV), the 422 status code signals that the request body is well-formed but semantically invalid. Unlike 400 Bad Request, which indicates malformed syntax, 422 means the syntax is correct but the data fails business logic or validation rules.

This status is widely adopted by REST APIs as the standard response for validation errors, replacing 400 in many modern frameworks.

When It’s Sent

• Validation failures — Required fields are missing, email format is invalid, or numeric fields contain text.
• Business rule violations — A discount code that has expired, or a booking date in the past.
• Duplicate entries — Creating a user with an email that already exists.
• Constraint violations — A value exceeds the allowed range or a string exceeds maximum length.
• State conflicts — Transitioning a resource to an invalid state (e.g., canceling an already-shipped order).

Real Example

The following curl command sends invalid data to trigger a 422:

curl -X POST https://httpbin.org/status/422 \
  -H "Content-Type: application/json" \
  -d '{"email": "not-an-email", "age": -5}' \
  -w "\nHTTP Status: %{http_code}\n"

Expected response:

HTTP/1.1 422 UNPROCESSABLE ENTITY
Date: Sat, 20 Jun 2026 12:00:00 GMT
Content-Type: application/json
Content-Length: 156

{
  "error": "Unprocessable Entity",
  "details": [
    {"field": "email", "message": "Must be a valid email address"},
    {"field": "age", "message": "Must be a positive integer"}
  ]
}

How to Debug & Fix

Client-Side

1. Validate before sending — Use client-side validation to catch errors before making the API call.
2. Read the error response — The response body typically includes detailed validation errors. Parse and display them to the user.
3. Fix each validation error — Correct the fields listed in the error details and retry.
4. Check for type mismatches — Ensure numbers are sent as numbers, not strings, unless the API accepts strings.
5. Verify required fields — Cross-check your payload against the API documentation for required fields.

Server-Side

1. Return detailed error messages — Include the field name, rejected value, and a human-readable message for each error.
2. Use consistent error format — Define a standard error response schema (e.g., JSON:API errors format).
3. Validate early — Validate input in middleware or at the controller boundary before business logic.
4. Log validation failures — Track common validation errors to identify API usability issues.

Common Causes Table

FAQ

Related Codes

HTTP 400 Bad Request — The request is syntactically malformed.

HTTP 415 Unsupported Media Type — The Content-Type is not supported.

HTTP 409 Conflict — The request conflicts with the current state of the resource.

HTTP 423 Locked — The resource is locked and cannot be modified.