The short version
- 01Read the response body for the field and validation code that failed.
- 02Supply required values using the endpoint's documented field names and types.
- 03Correct invalid formats and verify referenced resources through the normal application workflow.
- 04Resolve a duplicate value when the service requires a unique name or identifier.
- 05Change the invalid request data before retrying instead of repeating the same submission.
- 06Verify the accepted result and report unclear validation messages to the service owner.
Raw message
422 Unprocessable Content 422 Unprocessable Entity
Likely causes
- A required parameter is absent from an otherwise readable request.
- A field value has the wrong type or an invalid format.
- A supplied value conflicts with a provider's uniqueness requirement.
- A referenced resource or another application validation requirement is not satisfied.
Readable content can still be invalid for an operation
422 means the server understands the content type and syntax but cannot carry out the supplied instructions. You may also see the older reason phrase Unprocessable Entity. Treat the numeric code and the application's explanation together.
For example, a syntactically valid JSON object can still contain an unacceptable field value. Sending the identical object repeatedly does not correct that value. The meaningful next step is to read the validation result rather than change an already accepted media type.
If a form will not submit
Look for messages beside the fields as well as at the top of the form. Our recommendation is to keep your draft, correct the named requirement and submit again only after making that correction. An apparently filled field may still be in a format the service does not accept.
If only a bare 422 appears, tell support which action failed and whether any field was highlighted. Avoid sending private form contents unnecessarily. The owner needs to expose a useful validation explanation; the code alone does not tell a visitor which value to invent or replace.
If you maintain the client or validator
Use the endpoint's documented schema and error body. GitHub illustrates the distinction with codes such as missing_field, invalid and already_exists. Its API can also reject a parameter with the wrong type, such as an array where a string is required. These labels belong to GitHub; other services define their own error structure.
Our diagnostic sequence is to compare the exact serialized payload with a minimal valid example, change the field named in the error, and verify the resulting resource. Inspect all reported errors so fixing one does not leave another unnoticed. Do not convert every number to a string or drop every optional field as a permanent workaround without checking the contract.
For service owners, return actionable field information and preserve the distinction between parsing, format support and semantic validation. Clients should show recoverable validation errors to the user instead of placing unchanged submissions in an automatic retry loop.
Sources and review notes
Checked on . Based on HTTP semantics, MDN and GitHub validation documentation. Field-by-field comparison is editorial guidance; error labels and validation rules are provider-specific.