What does HTTP 422 mean?

Quick answer

HTTP 422 Unprocessable Content means the server understood the content type and the request body was syntactically correct, but the server could not process the instructions because the data failed validation. Clients should expect the same error if they repeat the request without modification MDN: 422 Unprocessable Content.

Typical causes include missing required fields, wrong data types, invalid formats and other business rule violations Postman: HTTP 422 guide.

When to return 422 vs 400 or 409

400 Bad Request

Use 400 when the request is malformed or framed incorrectly, such as invalid JSON, bad headers or unsupported media type. The issue is syntactic or structural MDN: HTTP status codes.

422 Unprocessable Content

Use 422 when the request is syntactically valid, but specific fields or values fail validation or business rules (for example, an invalid email or a date in the past) MDN: 422 Unprocessable Content. Many teams find this distinction helpful because clients can repair the data and resubmit. Individual APIs may vary, so follow the API's documentation.

409 Conflict

Use 409 when the request conflicts with the current state of the target resource (such as a version mismatch or a uniqueness conflict). The problem is resource state, not payload semantics MDN: HTTP status codes.

Designing useful 422 responses

Make 422 responses actionable for both humans and code. Include:

• A stable top-level error code and a concise human-readable message.
• Field-level details listing exactly which inputs failed and why.
• Clear guidance on allowed ranges, formats or enumerations where relevant.

Well-designed APIs return structured feedback that maps cleanly to forms and client-side validation Postman: HTTP 422 guide. Because 422 is a client error, retrying the same request without changes should not succeed MDN: 422 Unprocessable Content.

For easier debugging in distributed systems, include a correlation ID in error responses so clients can share a single reference when escalating issues. See our guide: Correlation IDs in APIs.

Example 422 responses you can adapt

Flat field map:

{
  "code": "validation_error",
  "message": "One or more fields failed validation",
  "errors": {
    "email": "invalid format",
    "startDate": "must be in the future"
  }
}

Nested structure with explicit paths:

{
  "code": "validation_error",
  "message": "Input invalid",
  "errors": [
    { "path": "attendees[0].email", "message": "invalid format", "code": "invalid_email" },
    { "path": "metadata.launchDate", "message": "date must be in the future" }
  ]
}

Common mistakes to avoid

• Returning 422 for server faults. Unexpected server errors belong to 5xx classes, while 422 is a 4xx client error MDN: HTTP status codes.
• Omitting field-level feedback. Without precise pointers, clients cannot reliably repair input Postman: HTTP 422 guide.
• Collapsing conflicts into 422. If the issue is the resource’s current state (for example, duplicate unique key), prefer 409 MDN: HTTP status codes.

If you need safe retries after conflicts, consider using idempotency keys to prevent duplicate actions: Idempotency keys: safe retries without duplicate actions.

Frequently asked questions

If you standardize when to return 422 and provide precise, stable error shapes, clients can repair requests quickly and integrate with far less guesswork.