Unprocessable Content

Server perspective

Use 422 when the request is well-formed and understood, but its instructions or values are semantically invalid.

When to use

• •Return 422 for validation failures, domain-rule violations, and semantically invalid content
• •Use it when the client can fix the submitted content without changing the target resource state

How to respond

• •Return field-level or rule-level validation details when possible
• •Keep 422 distinct from 400 syntax problems and 409 state conflicts

Headers to consider

• •No status-specific header is required; still send normal HTTP metadata such as Content-Type, caching, or tracing headers when they help the client.

Response body

• •Include actionable validation details such as field names, rule failures, or machine-readable error codes

Server-side pitfalls

• •Use 400 when the request could not be parsed or understood structurally
• •Use 409 when the problem is a conflict with current server state rather than bad submitted content

Examples