Qaynaq LABS · TOOLS

HTTP · 4xx Client Error

422 Unprocessable Entity

Server understands request but cannot process due to semantic errors in content.

When you see this status

  • POST/PUT request with valid JSON but invalid business logic
  • Form submission with invalid or missing required fields
  • API endpoint rejecting malformed or contradictory data
  • Validation failure in nested object structures

Common causes

  • Missing required fields in request body
  • Invalid data types (e.g., string instead of number)
  • Logical inconsistencies (e.g., start date after end date)
  • Schema validation failures in nested objects
  • Business rule violations (e.g., duplicate username)

How to debug it

  1. Inspect request payload for syntax errors
  2. Validate data against API schema definitions
  3. Check server-side validation logic
  4. Review business rule implementations
  5. Test with minimal payload to isolate issue

Return this code in your framework

Express (Node.js)
res.status(422).json({ errors: { field: 'Invalid value' } });
FastAPI (Python)
return JSONResponse(status_code=422, content={"detail": [{"loc": ["body", "field"], "msg": "Invalid value"}]})
NestJS
@HttpCode(422) @Post() async create(@Body() dto: CreateDto) { throw new UnprocessableEntityException('Invalid data'); }
Go (net/http)
w.WriteHeader(http.StatusUnprocessableEntity); w.Write([]byte(`{"error":"Invalid data"}`))

About HTTP 422

HTTP status code 422 Unprocessable Entity is part of the 4xx Client Error family. Server understands request but cannot process due to semantic errors in content. Understanding it is essential for backend engineers, API designers, and anyone debugging integrations between services.

The Qaynaq Labs HTTP Status Code Explainer covers all standard codes with practical guidance: what triggers them, how to debug them in production, and exactly how to return them from common frameworks. Each code page is hand-curated and verified.

Frequently asked

Is 422 the same as 400 Bad Request?

No. 422 indicates semantic validation errors, while 400 covers syntax or malformed requests.

Should 422 include error details in response?

Yes. Return structured error objects with field-specific messages for client-side handling.

Can 422 be used for authentication failures?

No. Use 401 (Unauthorized) or 403 (Forbidden) for authentication/authorization issues.

Is 422 idempotent?

Yes. Repeating the same request with invalid data will always return 422 until corrected.