HTTP 422 Unprocessable Content: Fix Validation Errors in APIs

A 422 means the server understood the request format and the syntax is fine, yet it cannot process the instructions because the content fails validation or business rules. The older name is "Unprocessable Entity", and you will still see it in frameworks and logs. The current standard calls it "Unprocessable Content". See the HTTP 422 reference.

It differs from 400, where the request is malformed or cannot be parsed, and from 415, where the format itself is not supported. A 422 means "valid JSON, but these values are not acceptable".

If you are a visitor

1. Read the message on the form. Highlighted fields tell you what failed, such as an invalid email, a password that is too short or a missing required value.
2. Fix and resubmit. If the page shows only "Unprocessable Content", re-check every field, especially dates, phone numbers and file types.
3. Reload the form page, then submit again. An expired session or security token (CSRF) can cause a 422 on frameworks like Rails.
4. Try another browser or a private window to rule out autofill and extensions inserting bad values.
5. Report it with the steps if every valid input fails; the validation rules may be buggy.

If you build the service or call the API

1. Read the body; it names the field

Most APIs return what failed:

{
  "message": "The given data was invalid.",
  "errors": {
    "email": ["The email must be a valid email address."],
    "age": ["The age must be at least 18."]
  }
}

That shape is Laravel's. FastAPI returns a detail array with loc, msg and type entries, and Rails apps typically return an errors object. Reproduce with curl and format the output using the JSON Formatter:

curl -i -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"email":"not-an-email","age":"seventeen"}'

2. Wrong types or formats

Strings where numbers are expected ("age": "17" versus 17), invalid date formats, enum values that do not match, and nested objects flattened by a client library are frequent. Check the schema in the API docs you use, and validate the document structure with the JSON Validator. In FastAPI, the Pydantic model defines the contract, and its error list gives the exact path to the bad field.

3. Missing required fields or extra ones

A forgotten field, or a field sent as null that the schema forbids, causes 422. So can unknown fields when the schema is strict (some Pydantic or JSON Schema setups forbid extras). Compare a working sample payload against yours field by field.

4. Business rules and uniqueness

Validation often covers rules such as "email already taken", "end date before start date" or "coupon expired". Laravel and Rails commonly respond 422 for uniqueness, while other APIs use 409 Conflict. Check your own conventions and keep them consistent.

5. Rails CSRF tokens and Authenticity errors

In Rails, an invalid or missing authenticity token raises ActionController::InvalidAuthenticityToken, which the app returns as 422. If your form works in the browser but fails from a script, either include the token and cookie, or use the API controller mode that skips CSRF for token-authenticated JSON. If the problem appears after a deploy or a cache change, a cached page may be serving an old token; exclude form pages from full-page caching.

6. Proxy and gateway interference

Rare, but a proxy that rewrites the body (compression, charset changes) or strips headers can make a valid payload invalid. Compare the same request direct to the app and through the public hostname. Inspect headers with the HTTP Header Checker.

Design tips for API authors

• Return 422 (or 400, but be consistent) with a machine-readable list of errors, each with a field path and a code.
• Use stable error codes for client logic and human messages for display.
• Validate on the client for convenience, but always on the server for safety.
• Never include internal details (stack traces, SQL) in validation responses.
• Write a test per rule that sends a bad value and checks the field name in the response.

Confirm the fix

Re-send the corrected request and expect a 200, 201 or 204. Use the HTTP Status Checker for public GET endpoints and your test suite for writes. Track error rates for key endpoints with an Uptime Monitor that checks a health or sample endpoint, so a bad deploy of validation logic is noticed quickly.

Next steps

• Read the HTTP 422 reference.
• Compare with 400 Bad Request.
• Learn how to monitor API endpoints.
• Browse developer tools for debugging requests.

FAQ

Is 422 the same as 400?

Not quite. 400 means the request is malformed or unparseable. 422 means it parsed correctly but the values fail validation.

Is "Unprocessable Entity" the same as "Unprocessable Content"?

Yes. The status code is the same. The name was updated in newer HTTP specifications.

Why do I get 422 only in production?

Look for different validation settings, database state (such as an existing unique value), expired CSRF tokens behind caching, or a proxy changing the request.

Should clients retry a 422?

No. Retrying the identical payload fails the same way. Fix the data first.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.