400 Bad Request vs 422 Unprocessable Entity

400 Bad Request?

The HTTP 400 Bad Request status code indicates that the server cannot or will not process the client's request due to an issue that is perceived to be a client error. This error signifies that the request sent to the server is malformed, invalid, or contains incorrect syntax, preventing the server from understanding and fulfilling it.

Major Causes Of HTTP 400

• Incorrectly formatted JSON
• Incorrectly formed requests missing parameters
• Incorrect values in the query string
• Requesting for unsupported media
• Request payload is too large

422 Unprocessable Entity?

The HTTP 422 Unprocessable Entity status code means that while the server was able to interpret the request sent, it is still not able to process it. The major issue here is when a server is capable of interpreting a request, understanding its message, format, and structure, but still cannot process due to some logical error.

Major Causes Of HTTP 422

• Failing validation constraints (for example: incorrect email format)
• Business rule violations (for example: trying to book an unavailable appointment)
• Domain-specific errors (for example: submitting an order with an out-of-stock item)

Background and History - The need of 422

Initially the HTTP/1.1 specification RFC 2616 did not define the 422 status code. So, the developers were using 400 as an umbrella covering most of the client side errors. But developers couldn’t find a status code for specific issues so it was later introduced in RFC 4918 (WebDAV) to differentiate between syntactic and semantic issues. RFC 4918, which extends HTTP for Web Distributed Authoring and Versioning (WebDAV), defined 422 to handle scenarios where request data could be parsed but not processed due to business or application logic constraints.

The introduction of 422 was intended to address the limitations of 400 Bad Request, which primarily focused on syntax errors. WebDAV needed a more granular distinction for cases where the request format was correct but the content itself was invalid for the intended operation. Over time, the 422 status code's usage expanded beyond WebDAV and became a common convention in RESTful APIs, particularly in scenarios involving input validation and business logic enforcement.

Modern web applications and APIs use 422 to signal issues like validation failures in JSON request bodies, enforcing constraints such as unique constraints, required fields, or business-specific logic (e.g., an order exceeding inventory limits). This differentiation helps clients understand whether they need to correct the syntax or the data being submitted.

Key Differences: 400 vs 422

Aspect	400 Bad Request	422 Unprocessable Entity
Syntax vs Logic	Syntax errors (e.g., JSON malformed)	Logical errors (e.g., validation failures)
RFC Origin	RFC 2616 (HTTP/1.1)	RFC 4918 (WebDAV)
Use Case	Structural issues in the request	Data conflicts or validation failures
Response	"Invalid request format"	"Invalid field value"
Who Prefers	Stripe, Twilio, Salesforce	Github, Shopify

Developer Perspective: Which One to Use?

You might’ve faced situations where choosing between 400 and 422 could be a task, let’s clarify the usage below:

• Use 400 if the request is malformed and cannot be processed at all. This applies when the request violates HTTP syntax rules, contains unsupported media types, or lacks required headers. Clients encountering a 400 error should understand that their request needs structural changes.

• Use 422 if the request is syntactically correct but fails due to business logic or validation constraints. This status code is ideal when you want to inform the client that they need to correct the submitted data rather than the request format itself.

Best Practices and Pitfalls to Avoid

Best Practices

• Always provide meaningful error messages in the response.
• Follow a consistent error response structure (e.g., error codes, messages, and field-level errors).
• Use 400 for syntax-related (serialization) issues and 422 for logical validation failures.
• Log error details server-side to diagnose recurring issues.

Common Pitfalls

• Misusing 400 for validation errors.
• Providing generic error messages without actionable details.
• Ignoring content-type negotiation.
• Failing to distinguish between syntax and semantic errors.

Examples: The 400 vs 422 battle!

Note:
While most services opt for 400 Bad Request for issues like missing headers, 422 Unprocessable Entity is the more appropriate choice when the request syntax is correct but semantically invalid. Choosing 422 helps differentiate between structural errors and logical validation failures.

GitHub Prefers 422

GitHub provides a practical example of this distinction. When a request contains an invalid JSON structure, such as syntax errors or malformed data, GitHub returns a 400 Bad Request response. However, when the JSON structure is correct but contains invalid data—such as trying to reference a non-existent repository branch—GitHub responds with 422 Unprocessable Entity. This approach helps developers understand whether they need to fix the format or the content of their request.

Example:

• If an API receives an invalid JSON payload such as {name: "beeceptor"} (missing quotes around name), respond with 400 Bad Request.
• If the JSON is correctly formatted but contains an email that already exists in the database, respond with 422 Unprocessable Entity.

Reference: GitHub API Docs

Shopify Prefers 422

A 400 Bad Request error occurs when Shopify cannot process the request due to issues like incorrect syntax, missing headers, or invalid parameters. For instance, failing to set the Content-Type to application/json or using an expired session token will result in this error. It indicates misconfiguration, requiring corrections in the request format. A 422 Unprocessable Entity error occurs when the request is well-formed but violates business rules. This happens in cases such as trying to purchase out-of-stock items or creating a product without a title. Shopify provides error details in the response to help pinpoint and resolve the issue.

Examples:

• A missing Content-Type header results in a 400 Bad Request.
• Creating a customer without an email or checking out products that are out of stock results in a 422 Unprocessable Entity.

Reference: Shopify API Docs

Stripe Prefers 400

Stripe responds with a 400 Bad Request error which indicates that the request was unacceptable, often due to missing a required parameter. Stripe primarily uses 400 for client-side validation errors and does not commonly use 422.

Example:

Sending a request without a required parameter results in a 400 Bad Request.

Reference: Stripe API Docs

Twilio Prefers 400

In Twilio, a 400 Bad Request response is triggered when the request contains missing or incorrect parameters. Twilio uses 400 for a wide range of client-side errors, such as authentication failures and improper request formatting.

Example:

A request with an incorrect authentication token results in a 400 Bad Request.

Reference: Twilio API Docs

Salesforce Prefers 400

Salesforce responds with a 400 Bad Request when it cannot understand the request, usually due to syntax errors in the JSON or XML body. Salesforce primarily relies on 400 for handling validation failures instead of 422.

Example:

An invalid JSON structure results in a 400 Bad Request.

Reference: Salesforce API Docs

Notion Prefers 400

Notion returns a 400 Bad Request response when the request is missing required headers, such as the Notion-Version header. If the version header is not provided or is incorrectly formatted, Notion will reject the request.

Example:

A request without the Notion-Version header results in a 400 Bad Request with the error message: "Notion-Version header failed validation: Notion-Version header should be defined, instead was undefined."

Reference: Notion API Docs

Frequently Asked Questions (FAQ)

Can I use 400 instead of 422 for all validation errors?

The 400 status code is broad and signals that the request in general is invalid, which includes errors like missing or incorrect data. On the other hand, 422 is more specific, meaning the server understands the request format but cannot process the data due to semantic errors, such as failed validation.

Is 422 specific to WebDAV?

No, the status code 422 is not specific to WebDAV. Although it was originally introduced in RFC 4918 as part of the Web Distributed Authoring and Versioning (WebDAV) extension to HTTP, its use has expanded beyond WebDAV.

What is the main difference between 400 and 422?

The main difference between HTTP 400 and 422 is that 400 (Bad Request) is used when the request has a syntactic issue, such as malformed JSON or missing parameters, making it structurally invalid. In contrast, 422 (Unprocessable Entity) is used when the request syntax is correct, but the data fails validation or business rules, meaning the server understands the request but cannot process it due to logical constraints.

Can HTTP 400 and 422 be used interchangeably?

No, the status code 400 and 422 should not be used interchangeably. The error codes indicate different types of issues: 400 signals a bad or malformed request, while 422 indicates that the request is understood but contains semantic errors. Using the correct status code is important for clarity and helps integrations by providing more accurate error handling.

How can I ensure consistent error handling in my API?

To ensure consistent error handling, use standard HTTP status codes, provide clear and structured error messages, and document errors in your API. Implement global error handlers and log errors for easier monitoring and debugging. Consistency helps both users and developers understand and address issues effectively.

Conclusion

Understanding the differences between HTTP 400 and 422 helps you design APIs that communicate errors effectively. Use 400 for syntactic errors and 422 for semantic validation issues to provide clear feedback to the caller (or your customers) and improve API usability.