What Is a 422 Status Code?

The use of HTTP status codes is critical in the web development world because it is a language used to communicate between you, a client (via your browser or mobile application), and a server. Status codes inform you about the outcome of a request that you have made. There are those that are well-known such as 404 Not Found or 500 Internal Server Error, others are less common. The 422-status code is one of these codes that are not well known.

In this Guide we shall deconstruct the meaning of a 422-status code, its occurrence, its difference with other similar codes, and the way developers and users may manage it.

Understanding HTTP Status Codes

It is vital to have a general idea of what the HTTP status codes are before delving into the 422-status code. The HTTP status codes are three-digit numbers that are sent by a server as an answer to a request made by a client.

These are categorized into five:

1xx – Informational: These codes mean that the request was accepted and is under processing.

2xx – Success: These codes are a result of a successful processing of a request. Such ones are 200 OK and 201 Created.

3xx – Redirection: These codes mean that the client is required to perform further action in order to fulfill the request. Three hundred and one moved permanently and three hundred and two found are examples.

4xx – Client Errors: The codes are an indication that something is wrong with the request of the client. They are 400 Bad Request, 401 Unauthorized and 404 Not Found.

5xx – Server Errors: The codes are used to show that the server has not responded to a valid request. They may be 500 Internal Server Error and 503 Service Unavailable.

The status code 422 is classified in the 4xx category of client error and this implies that the client had made a request that the server was unable to work on.

What Exactly Is a 422 Status Code?

The 422-status code stands for Unprocessable Entity.

A 422-status response is an indication that:

• The server is aware of the request contents and the syntax is not wrong.
• The server however is unable to execute the instructions in the request due to semantic error.

Simply, the client had submitted a request in the right format yet the data in the request was of invalid format which could not be processed by the server.

For example:

• Filling a form that lacks an email address that has the missing at symbol.
• The information sent has a field that is missing.

422 Status Code vs Other Common HTTP Errors

Understanding how the 422-status code differs from other common errors is key to troubleshooting effectively.

422 vs 400 Bad Request

400 Bad Request: This is a server error that occurs when the request is in a bad syntax or has an invalid format.

422 Unprocessable Entity: The server knows the syntax of the request, but it is not able to process it because of semantic errors.

Example:

Missing punctuations in information sent – 400 Bad Request.

Missing required field in information sent – 422 Unprocessable Entity.

422 vs 404 Not Found

404 Not Found: The resource that is being requested is not found on the server.

422 Unprocessable Entity: The resource is available and the format of the request is correct, however the request has invalid information.

422 vs 500 Internal Server Error

500 Internal Server Error: The server has had an unforeseen situation that could not allow it to process the request.

422 Unprocessable Entity: This is not a server error, but a client error. The client has to rectify the request.

Why Do 422 Status Codes Occur?

There are 422 errors that typically happen due to invalid data in a request, although the format of the request is correct.

Common reasons include:

Missing Required Fields

There are numerous applications which demand the presence of certain fields in requests. In case of the absence of a necessary field, the server can provide a 422-status code.

Example:

Leaving a sign-up form without a password or email.

Invalid Field Values

Although there are valid values in all fields, not all of them may have valid values.

Example:

• A field that has an invalid date such as the 13th month.
• A field of age with negative elements.

Data that is in violate of Business Rules

In some cases, the data can be grammatically good but it can be against the business guidelines of the application.

Example:

• Trying to register with an occupied email address.
• Placing an order quantity that is bigger than stock.

Unsupported Data Types

The wrong kind of data might be sent to cause a 422 error.

Example:

A field which is supposed to receive a number but gets a text.

Validation Errors

Validation error is a situation where the data in the request does not comply with some rules.

Examples include:

• Entering a user name which is too short.
• Leaving a non-valid email address format.
• Giving an invalid date (e.g. a birth date in the future).

Although the server can comprehend the request, it is unable to do so since the information is not logically correct.

Semantic Errors

Semantic errors occur when the content of the request is not logical in the application.

Examples include:

• Attempting to update a resource on which another resource is missing.
• Placing an order with a negative order quantity.

Sending data forms that are correct but incorrect in context (e.g. a string where an enum value is required).

Incomplete Data

The request might also contain 422 when it is syntactically correct but some fields are not present.

For example:

• Sending registration form without a password.
• Developing a product list without a product name or product price.

Common Scenarios Where 422 Occurs

Real-world situations could help to simplify the process of detecting and correcting 422 errors.

Scenario 1: Form Submission

Consider a web-based registration system at which the users would enter their name, email, and password. In case a user does not enter the password field, there is a possibility that the server will send a 422-status code since the request is incomplete though otherwise well-formed.

Scenario 2: API Requests

The most common error in working with the applications based on data submission is 422.

Example:

Request to create a new user is received, but some of the required fields are not filled. The server has knowledge of the request but it fails to process it because of invalid data.

Scenario 3: E-commerce Checkout

At checkout, when a customer attempts to use a coupon code that is not valid, or orders more products than are in stock, the server will give a 422-status code.

How to Handle a 422 Status Code

To deal with a 422 error, one will have to find the data that is invalid in the request and rectify it.

Here’s a step-by-step approach:

Identify the Error

A majority of the current applications will have a message stating the reason why the request was not completed. Examine the error details to be aware of the issue.

Example:

“Email field is required.”

Validate Data Before Sending

Make sure that all the necessary fields are filled and have relevant data. 422 errors can be avoided through validation.

Check Data Types

Ensure the type of data is appropriate to the server.

For example:

• Numbers should be contained in number fields.
• Numbers should not be permitted in the text fields where only text is allowed.

Follow Application Rules

Applications typically contain some rules regarding the required fields, permitted values and correct formatting. These rules can be followed to avoid 422 mistakes.

Handle Errors Gracefully

Rather than displaying a generic error, give specific feedback regarding the error and what to do to correct it.

Example:

The mail address is not valid. Please enter a valid email.”

Validate Data Before Sending

• Make sure that all necessary fields are there.
• Validating data format (emails, phone numbers, dates).
• Implement business constraints (e.g. minimum password length, positive quantity).

Display User-Friendly Error Messages

Rather than displaying a default message, give specific feedback:

• “User name should contain a minimum of 3 characters.
• “Email address is not valid.”
• Quantity will have to be more than none.

Explicit messages enable users to address problems in a short time.

Log Server Responses

Although 422 is a client error, recording responses assists developers in identifying trends and making validation rules better.

Best Practices to Prevent 422 Errors

It eliminates 422 errors and enhances user-friendliness and frustration.

Here are some best practices:

Front-End Validation

Check user input prior to transmission to the server.

This includes:

• Required fields
• Field length
• Data types
• Correct format (email, phone number, dates).

Server-Side Validation

Although front-end may be used to validate input, server-side validation is needed to ensure data integrity and security.

Clear Error Messages

Present users with accurate specific error messages. Never go with a generic message such as something went wrong.

Consistent Data Rules

Apply the same data submission rules on all platforms (websites, mobile applications, and APIs).

Automated Testing

Use automated testing to identify invalid requests before they get to production.

How Developers Use the 422 Status Code

Applications The 422-status code is used by developers of APIs and web applications.

Some key points:

• It indicates that there is some invalid data in the client request.
• A lot of web frameworks use 422 to denote processable entity errors.

A 422 response is a clear indication that there is an issue with the request that the client is making and not with the server.

422 Status Code in Popular Frameworks

These are the frameworks that deal with 422 errors:

Ruby on Rails

Saving records that are invalidated by validation is done with used for processable entity errors.

Django

Gives 422 in case of invalid data entries.

Laravel

Gives a decision of 422 on validation errors in case data fails application rules.

User Perspective: Seeing a 422 Status Code

For most users, a 422-status code is invisible because modern applications handle it gracefully.

However, if the error appears, users may see messages like:

• “Unprocessable Entity”
• The data you have entered could not be processed.

As a user experience point of view, the technical error should be converted to easy-to-understand instructions that assist the user in correcting the error.

422 Status Code vs 400 Status Code

Many developers confuse 422 with 400, but they have subtle differences:

 Key Takeaway

• 400 = the request is broken.
• 422 = the request is understandable but processable.

What Does the 422 Status Code Mean?

The 422 Unprocessable Entity status code is specified in the RFC 4918, which is an extension of the WebDAV protocol and is a supplement to HTTP. It means that the server recognizes the request, and the syntax is right, however, it is not able to execute the instructions because of semantic errors.

In simpler terms:

• The request is correctly formatted (there are no syntax errors).
• The server is able to comprehend the content.
• The server is not able to accept the request due to logical errors in the content it contains.

This is unlike a 400 Bad Request which is an indication that the request was not even understandable because the syntax was invalid or it was missing.

Key Characteristics of 422

The following are some of the peculiarities of the 422-status code:

Client-Side Error – This is a problem that is caused by the client and not the server.

Valid Syntax – The format of the request is proper.

Semantic Error – The information is not able to be processed because of corrupt data or logical errors.

Widely used in APIs – Particularly RESTful APIs and web applications where the data is in the form of a JSON or XML.

Real-World Use Cases

E-Commerce

• Invalid coupon codes.
• Negative quantities of products.
• Absence of shipping information.

Social Media Platforms

• Invalid username or handle.
• Use of more than the character limits in posts.
• Attempting to do things on resources that have been deleted.