Fix HTTP 422 Validation Errors in APIs
HTTP 422 commonly means the server understood the request representation but rejected its values or business meaning. Map each reported error to the exact input path.
Read the structured error response
Capture the request ID, stable error code, field path, rule, and safe message. Do not log credentials or private field values. A useful response distinguishes top-level business errors from field validation and uses machine-readable paths such as /customer/email or items[2].quantity. If the API returns only a generic message, add structured diagnostics at the validation boundary.
Separate syntax and semantic validation
First confirm that the body is valid JSON and matches the declared content type. A common convention uses 400 for malformed syntax and 422 for a syntactically valid body that violates schema or business rules. Other APIs use 400 for both. Follow the published contract rather than relying on status text alone.
Compare every field with the schema
Check required properties, nullability, string length, numeric bounds, enum values, array limits, uniqueness, and whether additional properties are allowed. Validate formats such as email, UUID, date, and date-time using the API's actual rules. Pay attention to quoted numbers, empty strings used instead of null, and seconds-versus-milliseconds timestamps.
Evaluate cross-field and business rules
Individual fields can be valid while their combination is not. An end date may precede a start date, a country may require a region, a selected plan may not support an option, or a quantity may exceed available stock. Return a stable code and paths for all involved fields. Avoid embedding volatile internal details in a client-visible message.
Keep server and client contracts aligned
A generated form or SDK may validate against an older schema than the deployed API. Compare the current OpenAPI document, client model, and server validator. Additive enum values and newly required fields can create unexpected failures. Treat a change that makes formerly valid requests fail as a compatibility decision and review it before deployment.
Correct input before retrying
An unchanged retry should fail again and only adds load. Fix the named values or refresh relevant state, then send a new request. Preserve user input locally so a form can show field-level errors without losing work. Validate safe samples with the JSON Schema Validator and inspect syntax using the JSON Validator.
Frequently Asked Questions
How does 422 differ from 400?
422 commonly identifies semantic validation after syntax was accepted.
Should an unchanged 422 be retried?
No. The input or relevant state must change.
Can business rules cause 422?
Yes. Cross-field and domain constraints are common causes.