Error: Cache Service Responded with 422

What is HTTP 422 Unprocessable Entity?

Unlike syntax errors that trigger 400 Bad Request, a 422 error means that the server understood your request structure but found problems with the actual content. The request syntax is correct, and the server understands the content type, but the payload contains invalid data or violates business rules.

The 422 status code comes from the WebDAV extension to HTTP and is commonly used in RESTful APIs for validation failures. While similar to 400 Bad Request, the distinction matters: 400 suggests malformed syntax, while 422 points specifically to logical or validation problems with otherwise well-formed data.

APIs typically return 422 status codes when validation fails, business rules are violated, referenced entities don’t exist, or operations conflict with the current state.

Common causes of HTTP 422 errors

Understanding why 422 errors occur helps you diagnose issues faster and build more resilient API integrations.

Missing required fields

APIs define certain fields as mandatory for specific operations. Omitting these fields triggers validation failures even when the request is otherwise properly structured.

Example of a request missing required fields:

POST /api/users HTTP/1.1
Content-Type: application/json

{
  "username": "developer123"
}

If the API requires both username and email, this request returns 422:

HTTP/1.1 422 Unprocessable Entity

{
  "error": "Validation failed",
  "details": [
    {
      "field": "email",
      "message": "Email is required"
    }
  ]
}

Invalid data types

Type mismatches occur when you send data in a format the API doesn’t expect. Common examples include sending strings where numbers are required.

Example with type mismatch:

POST /api/products HTTP/1.1
Content-Type: application/json

{
  "name": "Widget",
  "price": "29.99",
  "quantity": "15"
}

If price and quantity expect numeric types rather than strings, the API rejects this request with a 422 error.

Data format violations

Fields often have specific format requirements beyond basic types. Email addresses must match email patterns, phone numbers need proper formatting, and dates require specific formats like ISO 8601.

Example with format violations:

POST /api/contacts HTTP/1.1
Content-Type: application/json

{
  "name": "John Doe",
  "email": "john.doe@invalid",
  "birthdate": "05/15/1990"
}

This request fails validation if the email domain is invalid or the date format should be YYYY-MM-DD instead of MM/DD/YYYY.

Constraint violations

Business logic constraints ensure data integrity, including uniqueness requirements, range limits, and relationship dependencies.

Example attempting to create a duplicate:

POST /api/users HTTP/1.1
Content-Type: application/json

{
  "email": "[email protected]",
  "username": "newuser"
}

If the email already exists and the API enforces uniqueness, you’ll receive a 422 error indicating the duplicate violation.

How to troubleshoot HTTP 422 errors

Systematic diagnosis helps you identify the root cause quickly and implement the right fix.

Read the error response

Most well-designed APIs include detailed error messages explaining exactly what went wrong. Always examine the response body first.

The error response typically includes a human-readable message, specific field names that failed validation, details about what was wrong, and error codes for programmatic handling.

Example detailed error response:

HTTP/1.1 422 Unprocessable Entity

{
  "status": 422,
  "error": "Validation failed",
  "errors": [
    {
      "field": "email",
      "rejected_value": "invalid-email",
      "message": "Must be a valid email address"
    },
    {
      "field": "age",
      "rejected_value": -5,
      "message": "Must be between 0 and 150"
    }
  ]
}

Verify your request body

Confirm that your request includes all required fields with properly formatted data. Check that all mandatory fields are present, field names match exactly (including case sensitivity), data types match API expectations, and values fall within acceptable ranges.

Use JSON validators to catch syntax errors before sending requests. Even small formatting issues like trailing commas can cause problems.

Validate data types and formats

Confirm that every field uses the correct data type and format as specified in the API documentation.

Common type issues include numbers sent as strings, boolean values sent as strings ("true" instead of true), and dates in incorrect formats.

Example of correcting type issues:

// ❌ Incorrect types
{
  "price": "99.99",
  "in_stock": "true",
  "tags": "electronics"
}

// ✅ Correct types
{
  "price": 99.99,
  "in_stock": true,
  "tags": ["electronics"]
}

Review API documentation

API documentation specifies requirements, constraints, and expected formats. Key sections to check include required versus optional fields, data type specifications, validation rules, and example requests.

Check Content-Type headers

The Content-Type header tells the server how to interpret your request body. Mismatched headers cause parsing failures.

Common Content-Type values:

• application/json for JSON data

• application/x-www-form-urlencoded for form data

• multipart/form-data for file uploads

Ensure your Content-Type header matches your actual payload format:

POST /api/users HTTP/1.1
Content-Type: application/json

{
  "name": "Peter Postman",
  "email": "[email protected]"
}

Test with minimal data

Isolate the problem by starting with the bare minimum required fields, then gradually adding optional fields to identify which one triggers the error. This methodical approach pinpoints exactly which field causes the validation failure.

Testing and debugging in Postman

Postman provides tools specifically designed to help you diagnose and resolve validation errors.

Using the Postman Console

The Postman Console displays detailed request and response information essential for debugging 422 errors. To open the Console, click the Console icon in the bottom left, or go to View → Show Postman Console.

The Console shows information that might not display in the main response pane, including authentication headers and parsing details that help identify where validation failed.

Implementing pre-request validation

Pre-request scripts let you validate data before sending requests, catching issues early.

Example pre-request validation:

const body = JSON.parse(pm.request.body.raw);

if (!body.email) {
    throw new Error("Email is required");
}

if (!body.password || body.password.length < 8) {
    throw new Error("Password must be at least 8 characters");
}

const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
if (!emailRegex.test(body.email)) {
    throw new Error("Invalid email format");
}

Creating test assertions

Test scripts validate responses and help you understand exactly what validation failed.

Example test for 422 errors:

pm.test("Status code is 422", function () {
    pm.response.to.have.status(422);
});

pm.test("Response includes error details", function () {
    const response = pm.response.json();
    pm.expect(response).to.have.property('errors');
});

pm.test("Specific field validation failed", function () {
    const response = pm.response.json();
    const emailError = response.errors.find(e => e.field === 'email');
    pm.expect(emailError).to.exist;
    console.log("Validation error:", emailError.message);
});

These tests help you programmatically verify error responses and extract specific validation details for debugging.

Using mock servers

Postman’s mock servers let you simulate validation responses while developing, helping you build robust error handling before integrating with live APIs. Configure mocks to return 422 for invalid data, allowing you to test error-handling logic without actual API calls.

Best practices for preventing 422 errors

Building validation awareness into your development workflow reduces errors and creates more robust API integrations.

Validate input before sending requests

Client-side validation catches obvious issues before they reach the API. Implement validation for required field presence, data type correctness, format compliance for emails and dates, value ranges, and string length limits.

Use schema validation

JSON Schema provides a formal way to define and validate request structure, helping you catch issues during development. Define schemas that specify required fields, data types, and validation constraints.

Implement proper error handling

Your error handling should parse and display specific field errors, provide actionable feedback, log errors for debugging, and retry transient failures appropriately without retrying permanent validation failures.

Test edge cases

Deliberately test boundary conditions and invalid inputs to ensure error handling works correctly. Test scenarios should include empty strings, maximum values, special characters, malformed data types, and missing required fields.

Common mistakes to avoid

Assuming string representations work everywhere

Many APIs enforce strict type checking and won’t accept numbers wrapped in quotes.

// ❌ Wrong
{
  "user_id": "12345",
  "quantity": "5"
}

// ✅ Correct
{
  "user_id": 12345,
  "quantity": 5
}

Ignoring case sensitivity

Field names are often case-sensitive. userName and username are different fields. Always match field names exactly as shown in API documentation.

Sending incorrect date formats

APIs typically expect ISO 8601 format (YYYY-MM-DD or YYYY-MM-DDTHH:mm:ssZ).

// ❌ Wrong
{
  "birthdate": "05/15/1990"
}

// ✅ Correct
{
  "birthdate": "1990-05-15"
}

HTTP 422 vs other error codes

422 vs 400 Bad Request

400 Bad Request indicates malformed syntax that prevents the server from understanding the request, including invalid JSON or malformed headers.

422 Unprocessable Entity means the server understood the request perfectly but found semantic or logical errors in the data itself.

422 vs 409 Conflict

409 Conflict indicates the request conflicts with the current state of the resource, typically in concurrent modification scenarios.

422 Unprocessable Entity focuses specifically on validation failures rather than state conflicts.

Common issues and solutions

Issue	Solution
Missing required fields	Include all mandatory fields from API documentation.
Wrong data types	Use numeric types for numbers and booleans for true/false.
Invalid format	Use ISO 8601 dates and valid email patterns.
Incorrect Content-Type	Match header to payload format (JSON, form data).
Referenced resource doesn’t exist	Verify related entities exist first.
Duplicate values	Check uniqueness constraints.

Frequently asked questions

What does HTTP 422 mean?

HTTP 422 Unprocessable Entity indicates the server understood your request but cannot process it due to semantic errors, validation failures, or business rule violations.

Is 422 a client error or server error?

422 is a client error (4xx series), meaning the problem originates from the request data. The client needs to modify the request to resolve the error.

How is 422 different from 400?

400 Bad Request means malformed syntax. 422 means the request is well-formed but contains logically invalid data that fails validation.

Can I retry a 422 error?

Retrying without changes produces the same result. You must first correct the validation issues in your request data.

Why do I get 422 with correct JSON syntax?

JSON syntax correctness doesn’t guarantee semantic validity. Your structure may be perfect while still containing wrong data types, missing required fields, or values that violate business rules.

Should APIs return detailed error messages?

Well-designed APIs balance security with usability by providing enough detail to fix validation errors without exposing sensitive implementation details.