API input validation is one of the key elements that affect the security, quality and efficiency of an application. Validation is not limited to checking whether fields are required but also includes a number of other criteria that should be taken into account when testing the API. Care should be taken to ensure that the data is correct, secure, and that the API gives the user clear information about errors.
In addition to checking whether fields are required, it is also worth paying attention to additional aspects of validation.
Proper error messages are the foundation of a good interaction with the user (or the system that integrates with your API). If the API returns a generic message such as “Validation error,” the user may feel lost, not knowing what exactly is wrong with their data. Proper validation isn’t just about checking that the data is present, but also indicating precisely which data is wrong and how to correct it.
Example:
The expected API response when a user enters an incorrect email and/or phone number:
The standard server response in such a case is as follows:
{
"status": 400,
"message": "Bad Request"
} Why it’s not enough: Such a message does not provide any indication of a specific error. In the case of a form with multiple fields, the user does not know which field was filled in incorrectly. Without additional information, such as error details for each field, the user has to guess what’s wrong, which increases the troubleshooting time.
That’s why instead of default answers it’s a good idea to design one that clearly indicates the problem to be fixed.
{
"error": "Validation Errors",
"fields": [
{
"field": "email",
"message": "Email address is invalid. Please enter a valid email format, e.g., [email protected]"
},
{
"field": "phone_number",
"message": "Phone number must be 10 digits long and include only numbers."
}
]
} What are the advantages of this approach?
The API should not return generic error messages that only indicate a general problem but should indicate exactly which field failed and why.
The message contains a list of all the erroneous fields in the form, along with detailed instructions on how to fix the problem. This way the user knows exactly which data is incorrect and what he needs to do to make the query correct.
Data format validation is necessary to make sure that the data sent has the correct structure. Without it, the API may receive data that doesn’t make sense, and the server won’t be able to process it correctly.
If a user enters an email in the wrong format, the API should reject it and indicate an error.
{
"error": "Invalid input",
"details": {
"email": "Invalid email format. Example: [email protected]"
}
} If the API expects a date in the format YYYY-MM-DD, and the user enters DD-MM-YYYY, the API should reject such a format:
{
"error": "Invalid date format",
"message": "Please use the format YYYY-MM-DD"
} Why it’s important?
Validation of field lengths is very important to prevent excessive load on the system and incorrect data that can lead to errors in subsequent processing. It is important that the API returns an error when the data exceeds the specified maximum length.
Example:
If the API requires the username field to not exceed 20 characters, and the user enters a name that is 25 characters long, the API response should look like this:
{
"error": "Validation Error",
"message": "Username cannot be longer than 20 characters",
"field": "username"
} Why it’s important?
The API should be strongly specified, that is, it should reject any fields that are not expected in a given request. This prevents sending unnecessary information that can lead to excessive load on the system.
Example:
If a user sends an additional, unexpected nickname field, the API should return an error:
{
"error": "Unexpected field",
"message": "The 'nickname' field is not allowed",
"field": "nickname"
} Why it’s important?
The API should reject queries with duplicate keys. Two identical keys in the same query can lead to ambiguous data and processing errors.
Example:
If a query contains a duplicate email key:
{
"id": 123,
"email": "[email protected]",
"email": "[email protected]"
} The API should return an error:
{
"error": "Validation Error",
"message": "Duplicate key detected: 'email'",
"field": "email"
} Why it’s important?
Some data may be requested as query parameters or in the body, but the API should not allow parameters to be sent in two places. For example, if an email field has already been passed as a query parameter, it should not be in the body of the request.
Example:
Sending user data through the body and as a query parameter:
// Parameters in the URL
// query
{
"email": "[email protected]",
"name": "John"
} The API should return an error:
{
"error": "Validation Error",
"message": "The 'email' field cannot be passed in both the URL and body.",
"field": "email"
} Why it’s important?
If the user does not submit all the required fields, the API should return a 400 Bad Request error, not a 500 Internal Server Error. In the case of missing data (e.g., missing name, email address), the response should detail the missing fields.
Example: If a user fails to provide required fields such as email in a registration request:
{
"error": "Bad Request",
"message": "The 'email' field is required",
"field": "email"
} Why it’s important?
The API (the interface for communicating with the application) should respond appropriately if a user tries to perform an operation that cannot be performed on a given resource. For example, if a request is sent using a method that the endpoint does not support, the API should return an error.
Example:
If the API for users (/users) only supports the GET method (for retrieving data), and the user sends a query with the POST method (for creating data), the API should respond as follows:
{
"error": "Method Not Allowed",
"message": "POST method is not allowed for this endpoint"
} In this way, the API ensures that the user does not perform operations that are not allowed. Queries with unsupported methods are blocked, preventing accidental or unauthorized changes to the system.
Testing the validation of fields in the API is a key part of ensuring that the application works properly. Validation should not just be limited to checking that fields are required, but should also include other aspects, such as controlling the maximum character length of fields, eliminating duplicate keys, verifying the validity of the data format (e.g., email or date), and checking the content of parameters and fields in the query body to ensure that we are not sending redundant data or the same data in both the URL and body.
It’s also important that the API correctly verifies the presence of the required fields and returns a response with a code 400 for missing data, rather than generating server errors (500). Performing accurate data validation allows you to manage information accurately, protect your application from unauthorized manipulation, and improve the user experience by providing clear and helpful error messages.
TIP: The following checklist can be helpful in testing API validation:
Interested? Check out the next parts in this series:
What The API Says & What It Shouldn’t – The Hidden Dangers of Excess Data
API Testing Security Aspects – More Than Just Login Protection
Hicron’s contributions have been vital in making our product ready for commercialization. Their commitment to excellence, innovative solutions, and flexible approach were key factors in our successful collaboration.
I wholeheartedly recommend Hicron to any organization seeking a strategic long-term partnership, reliable and skilled partner for their technological needs.
After carefully evaluating suppliers, we decided to try a new approach and start working with a near-shore software house. Cooperation with Hicron Software House was something different, and it turned out to be a great success that brought added value to our company.
With HICRON’s creative ideas and fresh perspective, we reached a new level of our core platform and achieved our business goals.
Many thanks for what you did so far; we are looking forward to more in future!
Hicron is a partner who has provided excellent software development services. Their talented software engineers have a strong focus on collaboration and quality. They have helped us in achieving our goals across our cloud platforms at a good pace, without compromising on the quality of our services. Our partnership is professional and solution-focused!
The IT system supporting the work of retail outlets is the foundation of our business. The ability to optimize and adapt it to the needs of all entities in the PSA Group is of strategic importance and we consider it a step into the future. This project is a huge challenge: not only for us in terms of organization, but also for our partners – including Hicron – in terms of adapting the system to the needs and business models of PSA. Cooperation with Hicron consultants, taking into account their competences in the field of programming and processes specific to the automotive sector, gave us many reasons to be satisfied.
