Blog

The Only API Testing Checklist You Need in 2024

by Hannah Rivera | Jul 14, 2024 | API Testing, Blog, Top Picks | 0 comments

API testing is a critical aspect of software testing as APIs serve as the communication channels between different software components, allowing them to interact and exchange data. API testing not only involves validating the functionality, but also the performance, security, and reliability of APIs to ensure they meet the intended requirements and perform as expected. Ensuring that you’ve got complete coverage can be a challenge and that is why we have prepared this comprehensive API Testing Checklist based on our experience in delivering software testing services to our clients. Before we head to the checklist, let’s understand the criticality of API testing and the prerequisites you’ll need to follow the checks as well.

What Makes API Testing Crucial?

Although we gave you a brief overview of the API testing’s importance in the introduction, it would be better if you understand it in detail to ensure you can modify our API Testing checklist as per your varying requirements.

Functionality Validation:

API testing ensures that APIs function correctly and perform the intended operations. It verifies that the API endpoints return the expected responses, handle different scenarios, and adhere to the defined specifications and requirements.

Integration Testing:

APIs serve as the interfaces between different software components. API testing helps validate the integration of these components, ensuring smooth communication and data exchange between them. It helps identify any issues or inconsistencies in the integration process.

Performance and Scalability:

APIs often handle a significant volume of requests and need to perform efficiently and scale seamlessly. So you’ll have to assess the API’s response time, addition, and resource utilization under different payload conditions. It helps identify bottlenecks, optimize performance, and ensure scalability.

Security and Reliability:

APIs are also potential entry points for security vulnerabilities and attacks. That is why it is critical to maintain their security by identifying vulnerabilities like injection attacks, cross-site scripting (XSS), and authentication/authorization flaws. It helps ensure that APIs are secure, protect sensitive data, and follow industry best practices.

Version Compatibility:

APIs evolve in time with new versions introducing changes and improvements. So it is important to validate the compatibility between different API versions and ensures backward compatibility. It ensures that existing integrations and applications continue to function correctly when API versions are updated.

Error Handling and Exception Management:

APIs should handle errors and exceptions gracefully, returning meaningful error messages and appropriate status codes. API testing verifies that error handling mechanisms are in place and that the API responds appropriately to different error scenarios.

Pre-requisites for API Testing

Even with the API testing checklist in hand, you will not be able to perform the testing directly as there are a few prerequisites that have to be done from your end. So let’s see what those prerequisites are,

Understanding API Documentation:

Familiarize yourself with the API documentation available such as Swagger to understand the details about endpoints, parameters, expected responses, etc. This will play a crucial role in making changes to our API Testing checklist to align with your needs.

Setting Up the Test Environment:

Next up, you’ll need to ensure you have the test environment to do the tests. If a test environment isn’t available, make sure to set it up or reach out to the concerned team to get it done.

Identifying Test Data:

The next part is having test data to cover valid and invalid scenarios, edge cases, and boundary values. Establish a systematic approach for efficient test data management, encompassing the storage and organization of test data sets for reuse and maintenance.

Test Automation:

Test the APIs manually to conduct exploratory and feature testing. But to speed up the process, you can focus on implementing test automation to execute the repetitive tests and save time. You can use tools such as Postman, Rest Assured, or other tools mentioned below based on your preference.

Tools for API testing:

Since both manual and automation testing is required, choose the right API testing tools for your needs. Here’s a list of tools commonly used for API testing in both:

Manual API Testing Tools

• Postman
• Swagger UI
• cURL
• Insomnia
• SoapUI

Automation Testing Tools

• Postman (Automation)
• RestAssured in Java
• Requests In Python
• Karate DSL
• Fiddler

By addressing these prerequisites, you lay a foundation for a well-prepared environment with the right resources to execute the API testing checklist effectively.

Key Definitions

If you’ve already worked with APIs, you’ll be familiar with these terms. But if you’re just getting started, it is important that you are aware of these definitions to understand the checklist with ease.

Endpoints: It is a specified location within an API that accepts requests and returns responses.

Payload: The term “payload” denotes the information or data transmitted by the client in a request to the server, or the information provided by the server in response to a request.

Request: It is a question or a demand made by the user to a computer, asking for specific information or action.

Response: The answer or action taken by the receiving computer in response to the request.

Query parameters: They are provided at the end of the URL and are used to filter, and sort the data given by the API.

Key-value pairs: In key-value pairs, you’ll find a colon separating them, for example, “key”: “value” and the key remains static, serving as a consistent identifier.

API Testing Checklist

Now that we have seen the fundamentals, let’s head directly to the API testing checklist. We have categorized the checklist to help you understand and perform these checks with ease.

API Version

We start our API testing checklist with API version validation and it is the process of ensuring that an API behaves appropriately and consistently across different versions. APIs are frequently updated, with new versions being published to add features, repair issues, or enhance performance. However, these upgrades can occasionally introduce changes that alter the API’s behavior.

In API version validation, testers typically perform the following tasks:

• Testing forward compatibility: Check if older clients can still work with newer versions of the API. This ensures that new features added in the newer version do not break existing clients.
• Regression testing: Re-run existing test cases against the new version of the API to ensure that the core functionality remains intact and that new changes have not introduced any regressions.

Response Status code

The status code is an essential part of API responses as it indicates the success or failure of a request. Verifying the expected status code ensures that the API is functioning correctly and returning the appropriate status codes for different scenarios.

Example: If we expect a successful response, we will verify that the API returns a status code of 200 (Success). On the other hand, if we expect an error response, we would check for status codes like 400 (Bad Request) or 500 (Internal Server Error). Let’s take a deeper look at these responses in our API testing checklist now.

2xx Success Responses:

These codes confirm that the client’s request was successfully received.

• 200 OK: Signifying a successful request, the server returns the requested data.
• 201 Created: The server successfully processed the request, resulting in the creation of a new resource.
• 204 No Content: Although the request succeeded, the server does not provide any data in response.

4xx Client Error Responses:

These codes signify issues with the client’s request, such as mistyped URLs or invalid credentials. Prominent examples are:

• 400 Bad Request: The request is incorrect or invalid.
• 401 Unauthorized: The client lacks authorization to access the requested resource.
• 403 Forbidden: Although authenticated, the client lacks authorization to access the requested resource.
• 404 Not Found: The requested resource is not present on the server.

5xx Server Error Responses:

These codes reveal that the server encountered an error while attempting to fulfill the client’s request. Examples include:

• 500 Internal Server Error: A generic code indicating an unexpected condition preventing the server from fulfilling the request.
• 502 Bad Gateway error: It occurs when a gateway or proxy server receives an incorrect answer from an upstream server.
• 503 Service Unavailable: Issued when the server is temporarily unable to handle the request, often during high-traffic periods or maintenance.

Presence of JSON Elements

Next point in our API testing checklist is about JSON elements as API responses often include JSON data, which consists of key-value pairs. It is important to ensure that all the required JSON elements, or keys, are present in the response. This helps validate the response’s completeness and ensures that the expected data is returned.

Example: Suppose we expect an API response to include the following JSON elements: “name”, “age”, and “email”. We would verify that these elements are present in the response and contain the expected values.

Data Types for Response Values

API responses can contain data of different types, such as strings, numbers, booleans, or arrays. Validating the data types for response values ensures that the API returns the expected data types, which helps in maintaining data integrity and consistency.

Example: If we expect a response value to be a number, we will verify that the API returns a numeric value and not a string or any other data type.

Value Formats

Similar to the data type we saw previously in our API testing checklist, some API responses may include specific value formats, such as dates in the format MM/DD/YYYY. Validating value formats ensures that the API returns data in the expected format, which is important for compatibility and consistency with other systems or processes.

Example: If we expect a date value in the format MM/DD/YYYY, we have to verify that the API response follows this format and does not return dates in any other format such as DD/MM/YYYY or DD/MM/YY, etc.

Invalid Request Headers

When testing an API, it is important to verify how it handles invalid requests. Let’s start this part of our API testing checklist with invalid request headers by checking whether the API returns appropriate error messages when invalid or incorrect headers are provided.

Example: Suppose the API expects a valid access token in the “Authorization” header like this:

Authorization: Bearer <valid_access_token>

Now, during testing, you might intentionally introduce an invalid header, such as:

Authorization: Bearer <invalid_access_token>

Testing with this invalid header helps ensure that the API responds appropriately to unauthorized requests. The API should return a specific HTTP status code (e.g., 401 Unauthorized) and provide a clear error message, indicating that the provided access token is invalid or missing.

Invalid Request Body

Now that we have seen how invalid request headers should be managed, let’s check how invalid request bodies should be handled in our API testing checklist. When you send a request to an API, the request body often contains data in a specific format (e.g., JSON or XML). If the data in the request body is not well-formed or does not contain the mandatory fields, the API should respond with an appropriate error message.

Example: Consider an API that expects a JSON request body for creating a new user. The expected format might look like this:

{
  "username": "john_doe",
  "email": "[email protected]",
 "password": "secure password"
}

Now, during testing, you intentionally send a request with an invalid key:

{
  "username": "john_doe",
  "email": "[email protected]",
  "invalid_field": "securepassword"
}

In this example, the “invalid_field” is not expected in the API’s request body. The API should detect this issue and respond with an appropriate error message.

Header Parameter Limit

APIs often have certain limits or restrictions on header parameters, such as maximum character limits. To ensure that the API handles such scenarios correctly, we can test by hitting the API with more than the expected limit for a header parameter and verify the response.

Example: Suppose you have an API that expects a “Content-Length” header indicating the size of the request payload. The API may have a specified limit on the size of the payload it can accept, and exceeding this limit could lead to issues or security vulnerabilities.

The expected header might look like this:

Content-Length: 1000.

Now, during testing, you intentionally send a request with a “Content-Length” header exceeding the expected limit:

Content-Length: 2000

In this case, you are testing the API’s ability to handle oversized headers. The API should detect that the request header exceeds the defined limit and respond appropriately.

Invalid Header Parameter

Similar to sending header parameters beyond the defined limited, we have also included a check in our API testing checklist to see how an API handles invalid header parameters. It is important for maintaining security and data integrity. By sending invalid header parameters, we can ensure that the API rejects or handles them appropriately.

Example: If an API expects a header parameter called “X-API-Key”, we can test by sending an invalid or non-existent header parameter, such as “X-Invalid-Header: value”, and check if the API returns an error or handles it correctly.

Invalid Authorization Header Value

Authorization headers are often used to authenticate and authorize API requests. Testing with invalid authorization header values helps in verifying that the API rejects unauthorized requests and returns appropriate error messages.

Example: If an API expects an authorization header with a valid token, we can test by sending an invalid or expired token and check if the API returns an error indicating invalid authorization.

Valid Content-type values in the Request Header

Verifying an API request with valid Content-Type values in the request header involves testing how the API correctly processes different content types. The Content-Type header informs the server about the media type of the resource being sent or requested.

Example: Suppose you have an API endpoint for creating a new resource, and it accepts data in JSON or XML format. The valid Content-Type values might include:

JSON Content-Type:

POST /api/resources
Headers:
Content-Type: application/json
Request payload:
{
  "name": "New Resource",
  "description": "A description of the new resource"
}

XML Content-Type:

POST /api/resources
Headers:
Content-Type: application/xml
Request payload:
<resource>
  <name>New Resource</name>
  <description>A description of the new resource</description>
</resource>

Without Authorization Header Parameter

Similar to checking invalid header parameters previously in our API testing checklist, it is important to test how an API handles requests without the required authorization header parameter. This helps ensure that the API enforces proper authentication and authorization.

Example: If an API requires an authorization header parameter, we can test by sending a request without the authorization header and check if the API returns an error indicating the missing authorization.

Expired Authorization Token

When dealing with authorization tokens, it is important to test how the API handles expired tokens. By sending an expired token and hitting the API endpoint, we can verify that the API rejects the request and returns an appropriate error message.

Example: Consider an API that requires an “Authorization” header with a valid and non-expired access token for authentication. A valid authorization header might look like this.

Authorization: Bearer valid_access_token

Now, during testing, you intentionally send a request with an expired access token:

Authorization: Bearer expired_access_token

In this example, the API should detect the expired authorization token and respond with an appropriate error message. The expected behavior might include an HTTP status code, such as 401 Unauthorized, and a response body with a clear error message

Pagination

As pagination is a common technique used in APIs to retrieve data in chunks or pages, we have included a check for them in our API testing checklist. When testing pagination, it is important to verify whether the API returns the expected amount of data based on the specified data count limit for pagination.

Example: Suppose we want to retrieve 10 items per page using pagination. We would hit the API with the appropriate parameters and verify that the response contains exactly 10 items.

Valid Query Path Parameters

When verifying the response for an API endpoint with all the valid query path parameters, you are essentially checking how the API processes and responds to correctly formatted query parameters. We will also check for invalid query path parameters next in our API testing checklist. Let’s consider an example now:

Example: Suppose you have an API endpoint for retrieving information about a user, and it accepts several query parameters:

Endpoint: GET /api/users

Query parameters:

• userId (required): The ID of the user.
• includeDetails (optional): A boolean parameter to include additional details.

A valid API request with all the valid query path parameters might look like this:

GET /api/users?userId=123&includeDetails=true

In this example:

• userId is a required parameter, and it is set to 123.
• includeDetails is an optional parameter, and it is set to true.
• The expected response from the API should include the relevant information based on the provided parameters i.e. userId: 123.

{
  "userId": 123,
  "username": "john_doe",
  "email": "[email protected]",
  "details": {
    // Additional details based on the includeDetails parameter
    "age": 30,
    "location": "City"
  }
}

Invalid Query Path Parameter

Testing with invalid query path parameters helps in ensuring that the API handles such scenarios correctly and returns meaningful error messages.

Example: If an API endpoint expects a query path parameter called “id”, we can test by providing an invalid or non-existent value for this parameter and check if the API returns an error indicating the invalid parameter.

Special Characters in Query Path Parameter

The next check with regard to query path parameters in our API testing checklist is with special characters as it can sometimes cause issues or unexpected behavior in APIs. By testing with special characters in query path parameters, we can ensure that the API handles them correctly and returns the expected response.

Example: If an API expects a query path parameter called “name”, we can test by providing a value with special characters, such as “John&Doe”, and check if the API handles it properly.

Request Payload

Request payloads often contain data that is required for the API to process the request correctly. By verifying that all the required fields are present in the request payload, we can ensure that the API receives the necessary data.

Example: Suppose an API requires a request payload with fields like “name”, “email”, and “password”. We would verify that all these fields are present in the request payload before sending the API request.

Without a Request Payload

Similar to other checks in our API testing checklist, we should also test an API request without a request payload involves testing how the API handles scenarios where no data is provided in the request body.

Example: Suppose you have an API endpoint for creating a new user, and it requires certain fields in the request payload. But you didn’t provide any request body, the API should handle this scenario gracefully and respond appropriately. The expected response might include an HTTP status code, such as 400 Bad Request, and a response body with an error message indicating that the request payload is missing or malformed.

Without a Required Field in the Request Payload

To ensure data integrity and completeness, APIs often require certain fields in the request payload. By testing without a required field in the request payload, we can verify that the API returns the expected error message or response.

Example: If an API requires a request payload with a field called “email”, we can test by sending a request without the “email” field and check if the API returns an error indicating the missing field.

Invalid Data Types in the Request Payload

Next up in the set of request payload checks in our API testing checklist is to test with invalid data types in the request payload. APIs often have specific data type requirements for request payloads and so we have to ensure that the API handles them correctly and returns meaningful error messages even with invalid inputs.

Example: If an API expects a numeric field in the request payload, we can test by sending a string value instead and check if the API returns an error indicating the invalid data type.

Request Payload Length

Similar to other limitations seen in our API testing checklist, APIs also have limitations on the number of characters or the maximum length allowed for certain fields in the request payload. By testing with values exceeding these limits, we can ensure that the API handles them correctly and returns the expected response.

Example: If an API expects a field called “description” with a maximum limit of 100 characters, we can test by sending a value with more than 100 characters and check if the API returns an error indicating the exceeded limit.

Null Value in the Request Payload

Some APIs may allow certain fields to have null values in the request payload. By testing with null values for these fields, we can ensure that the API handles them correctly and returns the expected response.

Example: If an API expects a field called “address” in the request payload, we can test by sending a null value for this field and check if the API handles it properly.

Special Character in the Request Payload

Special characters can sometimes cause issues or unexpected behavior in APIs. By testing with special characters in fields of the request payload, we can ensure that the API handles them correctly and returns the expected response.

Example: If an API expects a field called “Contact” in the request payload, we can test by sending a value with special characters, such as “998877665$”, and check if the API handles it properly.

Valid Key-value Pair in the Query String Parameter

Next in our API testing checklist, we’re going to see a sequence of checks with the Query string parameters that are used to provide additional information to the API endpoint. By testing with valid key-value pairs in the query string parameters, we can ensure that the API correctly processes and returns the expected response based on the provided parameters.

Example: Suppose we have an API endpoint that expects query string parameters like “category” and “sort”. We can test by providing valid values for these parameters, such as “category=books” and “sort=price”, and verify that the API returns the appropriate response.

Invalid Key-value Pair in the Query String Parameter

Testing with invalid key-value pairs in the query string parameters helps ensure that the API handles such scenarios correctly and returns meaningful error messages.

Example: If an API endpoint expects a query string parameter called “page”, we can test by providing an invalid or non-existent key-value pair, such as “invalidKey=value”, and check if the API returns an error indicating the invalid parameter.

Different Data Types in the Query String Parameter

APIs may have specific data type requirements for query string parameters. By testing with different data types in the query string parameters, we can ensure that the API handles them correctly and returns meaningful error messages.

Example: If an API expects a query string parameter called “count” with a numeric data type, we can test by providing values of different data types as shown below,

"GET /api/products?count=10" (valid) 
"GET /api/products?count=somestring" (invalid),  

It should return the appropriate error code or message when it is an invalid parameter.

Valid Date Format Key-value pair in the Query String Parameter

The final check with the query string parameters in our API testing checklist is with the valid date format. Some APIs may require specific date formats in the query string parameters. By testing with valid date formats, we can ensure that the API correctly processes and returns the expected response based on the provided date.

Example: If an API expects a query string parameter called “date” in the format “YYYY-MM-DD”, we can test by providing a value like

"GET /api/products?date=2024-02-16" 

We can ensure it returns the appropriate response message or code.

Server Request Per Second Configuration

We’re now moving towards the performance part of our API testing checklist. To test the performance and rate-limiting capabilities of an API, we can hit the API multiple times within a short period to exceed the configured request per second limit. This helps verify that the API enforces the rate limit and returns the expected response or error message.

Example: If an API has a rate limit of 10 requests per second, we can test by sending more than 10 requests within a second and check if the API returns an error indicating the exceeded limit. It could respond with an error code, such as 429 Too Many Requests, indicating that the rate limit has been exceeded.

Concurrent Rate Limit

Similar to testing the rate limit per second, we can also test the allowed concurrent rate limit of an API by sending multiple concurrent requests. This helps in verifying that the API handles concurrent requests correctly and returns the expected response or error message.

Example: If an API allows a maximum of 100 concurrent requests, we can test by sending 100 or more concurrent requests and check if the API handles them properly.

Expected Responses:

• If the concurrent rate limit is not exceeded, all requests ( more than 100) should receive successful responses.
• If the concurrent rate limit is exceeded, the API should respond in a controlled manner, possibly by returning an error response indicating that the concurrent rate limit has been surpassed.

Uploads and Downloads

If an API supports file uploads and downloads, it is important to test this functionality to ensure that the API handles the file transfer correctly. By uploading and downloading files, we can verify that the API correctly processes and returns the expected files. We will further break this point in our API testing checklist.

File Uploads

Check File Type and Size:

• Verify that the API checks the file type and size during the upload process.
• Test with various file types, including both allowed and disallowed types, and files exceeding the maximum size.

Validate File Name and Content:

• Verify that the API sanitizes and validates the file name to prevent any potential security issues.
• Check if the API validates the content of the uploaded file to ensure it matches the expected format (e.g., for image uploads).

Handle Concurrent Uploads:

• Test the API’s behavior when multiple users attempt to upload files simultaneously.
• Check if the API maintains proper concurrency control and prevents race conditions during file uploads.

Test Timeout and Large Files:

• Verify that the API gracefully handles long upload times and does not time out prematurely.
• Test the API’s behavior with very large files to ensure it can handle the load without crashing.

Authentication and Authorization:

• Make sure that file uploads are only done by authorized users.
• Verify that the API enforces proper authentication and authorization checks before processing file uploads.

File Downloads:

Check Access Controls:

• Test if the API correctly enforces access controls for file downloads. Unauthorized users should not be able to access sensitive files.
• Verify that the API checks user permissions before allowing file downloads.

Test Download Speed and Efficiency:

• Assess the download speed and efficiency by downloading various file sizes.
• Ensure that the API efficiently streams large files and does not consume excessive resources.

Secure File Transmission:

• Ensure that file downloads are conducted over secure connections (HTTPS) to prevent man-in-the-middle attacks.
• Verify that the API supports secure protocols for file transmission.

Specific Time Zone in the Request Payload

The Accept-Timezone header allows the client to specify the desired timezone for the API response. By testing with specific timezone values in the Accept-Timezone header, we can ensure that the API correctly processes and returns the response in the specified timezone.

Example: If an API supports the Accept-Timezone header, we can test by setting the header value to a specific timezone, such as “Accept-Timezone: America/New_York”, and verify that the API returns the response in the specified timezone.

Managing SSL/TLS Certificates

SSL/TLS certificates are essential for securing API communications over HTTPS and that is why we have added it to our API testing checklist. By testing the API with different SSL/TLS certificates, including valid, expired, or self-signed certificates, we can ensure that the API handles them correctly and returns the expected HTTP status codes.

Example: If an API requires a valid SSL/TLS certificate, we can test by accessing the API with a self-signed or expired certificate and verify that the API returns an appropriate error indicating the certificate issue.

Server log Information

The final point of our API testing checklist is to monitor server logs as it is crucial for debugging and troubleshooting API issues. By testing the API and checking the server logs, we can ensure that the API requests are logged correctly and provide valuable information for diagnosing any errors or unexpected behavior.

Example: After making API requests, we can access the server logs and verify that the relevant information, such as the request method, path, and response status, is logged correctly.

Conclusion

We hope our comprehensive API testing checklist will ease your API testing process to give great coverage. By following this checklist and testing each item, we can ensure that the API functions correctly, handles various scenarios, and returns the expected responses. Testing systematically and thoroughly helps in identifying and fixing any issues, ensuring the reliability and quality of the API. Remember to adapt the checklist based on the specific requirements and functionalities of the API you would like to test.