API Testing Full Notes PDF for QA
We provide API Testing Notes for QA, API Testing Fundamentals covers how to test APIs, validate requests and responses, verify status codes, check data accuracy, handle errors, and ensure reliable communication between applications using tools like Postman.

1. What is an API?

API stands for Application Programming Interface.

An API allows two software applications to communicate with each other and exchange information.

For example, when you use a food delivery app, it needs information about restaurants, menus, prices, and orders. APIs help different systems exchange this information.

In simple words: An API acts like a bridge between two software applications.

Webvittha.com

2. What is API Testing?

API Testing is the process of checking whether an API works correctly.

A tester sends requests to an API and checks the responses to make sure the API returns the correct information.

Example: A login API receives a username and password. The tester checks whether valid credentials return a successful response and invalid credentials return the expected error.

API testing commonly checks:

Response status code.
Response data.
Response time.
Authentication and authorization.
Error messages.
Data correctness.

3. Why Do We Need API Testing?

API testing is important because applications often depend on multiple services communicating with each other.

If an API fails, features such as login, payments, product searches, or order tracking may stop working.

Example: A shopping app allows users to place orders. If the order API saves the wrong quantity, customers may receive incorrect orders.

API testing helps identify such problems before they affect users.

4. What Is the Purpose of API Testing?

The purpose of API testing is to verify that APIs behave according to their requirements.

Its main purposes are:

Check whether requests work correctly.
Verify the response data.
Validate status codes and error messages.
Check security and access permissions.
Identify performance problems.
Verify communication between systems.

Example: When a user requests order details, the API should return the correct order belonging to that user, not another customer’s order.

Module 4: HTTP Methods

Understand the purpose, behavior, and testing of each HTTP method.

Method	Purpose	Testing focus
GET	Retrieve data	Correct response and data
POST	Create or submit data	Resource creation and validation
PUT	Replace a resource	Full update behavior
PATCH	Partially update a resource	Only intended fields change
DELETE	Delete a resource	Deletion and subsequent retrieval
HEAD	Retrieve response headers	Headers without response body
OPTIONS	Discover supported operations	Allowed methods and CORS behavior

Additional topics:

Safe and idempotent methods
GET vs POST
PUT vs PATCH
POST vs PUT
DELETE behavior
Idempotency keys
Method restrictions
Testing unsupported HTTP methods

Module 5: HTTP Status Codes

What are HTTP status codes?
Why are status codes important?
1xx — Informational responses
2xx — Successful responses
3xx — Redirection responses
4xx — Client errors
5xx — Server errors

Important status codes to understand:

200 OK
201 Created
202 Accepted
204 No Content
301 Moved Permanently
302 Found
304 Not Modified
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
408 Request Timeout
409 Conflict
415 Unsupported Media Type
422 Unprocessable Content
429 Too Many Requests
500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout

Practical exercises:

Verify expected status codes.
Verify incorrect status codes.
Check status codes for invalid input.
Test missing resources.
Test unauthorized requests.
Verify error responses and messages.

5. What Is an API in Simple Terms?

Imagine you are sitting in a restaurant.

You are the customer.
The waiter takes your order.
The kitchen prepares your food.
The waiter brings your food back.

An API works similarly. One application sends a request, another system processes it, and a response is returned.

Client application

Customer places a request

API

Carries the request and response

Server / Backend

Processes the request and prepares the result

The API is not necessarily a separate physical system. It is an interface that defines how software components communicate.

6. Real-World Examples of APIs

APIs are used in many everyday applications.

Application	How an API is used
Food delivery	Retrieves menus and submits orders
Banking	Retrieves account balances and transaction details
E-commerce	Searches products and creates orders
Weather app	Retrieves current weather information
Maps	Retrieves routes and location information
Online payments	Sends payment requests and receives payment status
Social media	Retrieves posts and profile information

Example: When you check the weather on your phone, the app may request weather data from a remote service through an API.

7. How APIs Work

An API generally works through the following steps:

The client sends a request.
The API receives the request.
The server validates the request and checks permissions.
The server performs the required operation.
The server prepares a response.
The client receives and uses the response.

Example: When a user searches for a product, the application sends a search request. The server searches its data and returns matching products.

An API may return data in JSON, XML, or another supported format.

8. Client-Server Architecture

Client-server architecture is a model in which a client requests a service and a server provides it.

Client: The application or system making the request.

Server: The system that receives the request, processes it, and returns a response.

Examples of clients include web browsers, mobile applications, and other backend services.

Example: When you log in to an online banking application, the application acts as the client, while the banking backend processes the login request.

The client and server communicate through a network, often using HTTP or HTTPS.

9. Request and Response Cycle

The request and response cycle describes how a client communicates with a server.

A request contains the information the client sends. A response contains the result returned by the server.

An HTTP request may include:

URL or endpoint.
HTTP method.
Headers.
Query parameters.
Request body.

An HTTP response may include:

Status code.
Response headers.
Response body.
Timing information.

Example:

Request:

</>http

GET /users/101

Response:

</> JSON

{  "id": 101,  "name": "Rahul"}

This example represents a request to retrieve user information. The exact URL and response depend on the API being tested.

10. What Is an API Endpoint?

An API endpoint is a specific address where an API resource or operation can be accessed.

For example:

</> Plain Text

https://api.example.com/users

https://api.example.com/products

https://api.example.com/orders

These endpoints may provide access to users, products, and orders.

Example: A tester sends a request to the users endpoint to retrieve a list of users and checks whether the response is correct.

The HTTP method also matters. A GET request and a POST request to the same path may perform different operations.

11. What Is an API URL?

An API URL is the address used to access an API resource or operation.

For example:

</> Plain Text

https://api.example.com/products/25

Its parts are:

https — the communication protocol.
api.example.com — the host or domain.
/products/25 — the path identifying the resource.

A URL may also contain query parameters.

Example:

</> Plain Text

https://api.example.com/products?category=mobile

Here, category=mobile is a query parameter that may filter the products.

Difference: A URL is the complete address, while an endpoint commonly refers to the particular API access point or route.

12. What Is an API Contract?

An API contract defines the agreed rules for communication between the API provider and its consumers.

It describes what the API accepts and what it returns.

A contract may specify:

Endpoint paths.
HTTP methods.
Required parameters.
Request body structure.
Response format.
Status codes.
Authentication requirements.
Validation rules.

Example: A registration API requires an email address and password. If the email address is missing, the contract may specify that the API returns a validation error.

API testing checks whether the actual behavior matches the agreed contract.

13. What Is an API Specification?

An API specification is a structured description of how an API works and how it should be used.

It may describe the available endpoints, methods, parameters, request bodies, response schemas, and security requirements.

A commonly used format is OpenAPI, which is often used to document REST APIs.

Example: A tester reads the API specification and learns that the login endpoint requires a POST request with an email address and password.

The tester then creates test cases based on those requirements.

Difference: The contract focuses on the agreed behavior and rules; the specification is a document or machine-readable description that can define those rules.

14. What Is an API Provider and API Consumer?

API provider: The organization or system that creates and makes the API available.

API consumer: The application or system that uses the API.

Example: A payment company provides an API that allows an online shopping website to process payments.

The payment service is the API provider.
The shopping website is the API consumer.

A single application can be both a provider and a consumer if it exposes some APIs and uses other APIs.

15. What Is an API Gateway?

An API gateway is a component that acts as an entry point for requests going to one or more backend services.

It can help manage API traffic and apply shared rules.

Common responsibilities include:

Routing requests to backend services.
Authentication and access control.
Rate limiting.
Logging and monitoring.
Request or response transformations.

Example: A shopping application may send product, order, and customer requests through one API gateway. The gateway routes each request to the appropriate service.

An API gateway does not replace the backend services; it helps manage communication with them.

16. What Is API Integration?

API integration means connecting different applications or systems so they can exchange data and work together.

Example: An online store connects to a payment service using an API.

When a customer places an order:

The store sends a payment request.
The payment service processes it.
The payment service returns the result.
The store updates the order status.

API integration testing verifies that the connected systems exchange the correct information and handle successful and failed scenarios properly.

17. API Testing vs UI Testing

API testing and UI testing check different parts of an application.

API Testing	UI Testing
Tests application interfaces used for communication	Tests the visible user interface
Sends requests directly to APIs	Interacts with buttons, forms, menus, and pages
Checks responses, data, and status codes	Checks display, navigation, and user interactions
Usually does not require a graphical interface	Usually requires a browser or application interface
Often faster for checking backend behavior	May be slower because it includes rendering and interactions

Example: For a login feature:

API testing checks whether the login endpoint accepts valid credentials and rejects invalid ones.
UI testing checks whether the user can enter credentials, click Login, and see the correct page or error message.

Both are useful and complement each other.

18. API Testing vs Unit Testing

Unit testing checks a small, isolated part of the code, such as a single function or method.

API testing checks an API’s externally observable behavior, such as the request it receives and the response it returns.

API Testing	Unit Testing
Checks an API interface and its behavior	Checks an individual unit of code
May involve several backend components	Usually isolates one component
Often sends actual HTTP requests	Often calls code directly without HTTP
Can verify response schemas and status codes	Can verify calculations, conditions, and individual functions

Example: In a banking application:

A unit test checks whether an interest calculation function returns the correct value.
An API test checks whether the account balance endpoint returns the correct balance and response status.

API tests can also be written at different levels, so the exact boundary depends on the system and test design.

19. API Testing vs Integration Testing

API testing checks whether an API behaves correctly according to its requirements.

Integration testing checks whether different components or systems work correctly together.

These concepts overlap because API tests often verify integration between services.

API Testing	Integration Testing
Focuses on API requests, responses, and contract behavior	Focuses on interactions between components
Checks status codes, data, validation, and access	Checks data flow and cooperation between systems
Can test an API in isolation from some dependencies	Often verifies multiple connected components
May use mocked dependencies	May use real or simulated dependencies

Example: A payment API test checks whether a payment request returns the expected status.

An integration test checks whether the shopping application, payment service, and order system correctly update an order after payment succeeds or fails.

20. Advantages and Limitations of API Testing

Advantages

Fast execution: API tests often run faster than UI tests.
Early defect detection: Backend issues can be identified before the UI is complete.
Better data validation: Responses and business rules can be checked directly.
Automation-friendly: Tests can run repeatedly during development.
Security checks: Authentication and authorization behavior can be tested.
Technology flexibility: APIs can be tested without relying on a particular frontend framework.

Limitations

Technical knowledge required: Testers need to understand requests, responses, HTTP, and data formats.
Test data challenges: APIs may require specific users, accounts, or records.
Dependency issues: External services may be unavailable or unstable.
Limited UI coverage: API testing does not verify layout, colors, button placement, or visual usability.
Authentication complexity: Tokens, permissions, and access rules may require additional setup.
Environment differences: API behavior can vary across development, testing, and production environments.

API testing is powerful, but it should be combined with other testing methods to provide broader quality coverage.

21. When Should API Testing Be Performed?

API testing can be performed throughout the software development lifecycle.

During development: Test new endpoints as they are created.
Before UI completion: Verify backend behavior even when the frontend is unfinished.
During integration: Check communication between connected systems.
During regression testing: Confirm that code changes have not broken existing API behavior.
Before release: Validate important business flows, security rules, and response correctness.
After deployment: Run appropriate smoke tests to check whether critical APIs are available and working.

Example: Before releasing a shopping application, the QA team tests login, product search, cart, order creation, and payment-related APIs.

The earlier defects are detected, the easier they can often be to fix.

22. Role of an API Tester in a Software Project

An API tester checks whether APIs work correctly, securely, and according to the documented requirements.

Common responsibilities include:

Understand API requirements and specifications.
Identify endpoints and HTTP methods.
Prepare positive and negative test cases.
Send API requests using tools such as Postman.
Validate response status codes and data.
Check required fields, data types, and response schemas.
Test authentication and authorization.
Verify error messages and input validation.
Check response time and basic performance requirements.
Report defects with clear reproduction steps.
Retest fixes and perform regression testing.
Automate repetitive API tests where appropriate.
Collaborate with developers, manual testers, and other QA team members.

Example: A developer creates an API for registering new users. The API tester checks successful registration, duplicate email addresses, missing fields, invalid formats, unauthorized requests, and the correctness of the returned response.

The tester then reports any defects and verifies the fixes.

Quick Revision for Beginners

Term	Easy meaning
API	Allows software applications to communicate
API testing	Checks whether an API works correctly
Client	Sends a request
Server	Processes a request and returns a response
Request	Information sent to an API
Response	Information returned by an API
Endpoint	A specific API access point
API URL	The address used to access an API
Contract	Agreed rules for API behavior
Specification	Structured description of an API
Provider	Makes an API available
Consumer	Uses an API
API gateway	Manages and routes API requests
API integration	Connects systems through APIs
Status code	Indicates the result of an HTTP request
API tester	Verifies API behavior, data, and requirements

What to learn next: After understanding these fundamentals, study HTTP methods (GET, POST, PUT, PATCH, DELETE), status codes (200, 201, 400, 401, 403, 404, 500), headers, query parameters, request bodies, JSON, and Postman.

These topics will help you move from understanding APIs to performing practical API testing.

Module : Positive and Negative Testing

Positive Testing

Send valid input data.
Verify successful responses.
Check correct data creation and retrieval.
Verify valid authentication.
Confirm correct updates and deletions.

Negative Testing

Send missing mandatory fields.
Send invalid data types.
Send incorrect formats and boundary values.
Send invalid or expired tokens.
Test nonexistent IDs and duplicate records.
Send malformed JSON and unsupported methods.
Verify appropriate errors without exposing sensitive data.

Module : CRUD Operations — Real-Time Functionality

CRUD means Create, Read, Update and Delete.

Functionality	Method	Main validations
Create user	POST	Required fields, ID generation, duplicate handling
Get user	GET	Correct ID and returned data
Update user	PUT	Updated resource and field values
Partial update	PATCH	Only intended fields change
Delete user	DELETE	Correct deletion and subsequent retrieval

You should know how to test the entire workflow, including invalid requests, data persistence, duplicate submissions, and database consistency where access is available.

Module : Most Important Interview Scenarios

Practise answering these questions aloud.

1. An API returns 200 OK, but the response data is incorrect. Is it a bug?Yes, if the response violates the requirements. Verify the response body, expected data, test environment, and backend records if accessible. Report the mismatch with request and response evidence.

2. How would you test a login API?

Test valid credentials, invalid password, unknown user, missing fields, malformed input, locked or disabled accounts, token generation, token expiry, response data and rate limiting.

3. How would you test a user registration API?

Test valid registration, required fields, email format, duplicate email, password rules, boundary values, invalid data types, status code, generated ID and persistence.

4. What is the difference between 401 and 403?

401 indicates missing or invalid authentication credentials in typical APIs. 403 means the request is understood but access is not permitted.

5. How do you test a DELETE API?

Verify the expected success response, confirm the resource is deleted using GET or another authorized check, test nonexistent IDs, permissions and repeated deletion behavior.

6. How do you validate a JSON response?

Check status code, required keys, data types, values, arrays, nested objects, null handling, headers and schema against the API requirements.

7. How would you test an API without UI access?

Use API documentation and tools such as Postman or curl. Validate requests, responses, business rules, errors, authentication and data consistency.

8. How do you report an API defect?

Include the endpoint, method, environment, test data, headers with secrets removed, request body, actual and expected results, status code, response body and reproduction steps.

9. What would you test if an API is slow?

Measure response times over repeated requests, check payload size and network conditions, review latency percentiles and error rates, and compare against agreed performance requirements.

10. How do you test authorization?

Test users with different roles, access to their own and other users’ resources, restricted functions, missing permissions and attempts to access sensitive fields.

Module : Request and Response Validation

API Testing Notes | Beginner to Experienced QA | QAPage Learning

Request and Response Validation is one of the most important parts of API testing. It checks whether an API receives the correct information and returns the expected result.

For example, when a user logs in to a website, the tester checks the request sent to the login API and verifies whether the response contains the correct status code, message, user details, and data format.

We will use a simple online shopping API as an example throughout these notes.

1. Base URL and Endpoint

The Base URL is the common starting address of an API. An endpoint is the specific path used to access a resource or perform an operation.

Example:

Base URL:https://api.shopdemo.comEndpoint:/productsComplete URL:https://api.shopdemo.com/products

Another endpoint could be /orders to access order information.

What should a tester check?

Is the base URL correct?
Is the endpoint path correct?
Does the endpoint exist?
Does it return the expected response?
Does the endpoint work in the correct environment, such as QA or staging?

Real-time scenario: If the product API is configured with the wrong base URL, the tester may receive a connection error or an unexpected response.

2. Path Parameters

Path parameters identify a specific resource within an endpoint.

Example:

GET /products/101

Here, 101 is the product ID.

A complete URL could be:

https://api.shopdemo.com/products/101

This request asks the server to return the product with ID 101.

Test scenarios:

Send a valid product ID.
Send a product ID that does not exist.
Send an invalid ID format.
Check how zero or negative IDs are handled, if applicable.
Verify that the returned product ID matches the requested ID.

Expected result: A valid ID should return the correct product. An unknown ID should produce the documented not-found response or other specified behavior.

3. Query Parameters

Query parameters are added to a URL after a question mark (?). They are commonly used to filter, search, sort, or paginate results.

Example:

GET /products?category=mobile&limit=10

Here:

category=mobile filters products by category.
limit=10 requests up to ten results, if supported by the API.

Multiple query parameters are separated by &.

Test scenarios:

Search with a valid category.
Search with an unsupported category.
Check behavior when a parameter is missing.
Test minimum, maximum, and invalid values for limit.
Verify that the returned products match the filters.

Real-time scenario: If the API returns laptop products when the request asks for mobile products, the filter may not be working correctly.

4. Request Headers

Request headers provide additional information to the server about the request.

Example:

GET /products/101 HTTP/1.1Host: api.shopdemo.comAccept: application/jsonAuthorization: Bearer <token>

Common headers include:

Authorization — provides credentials or an access token.
Content-Type — describes the format of the request body.
Accept — indicates the response formats the client can accept.
User-Agent — identifies the requesting software in some contexts.

What should a tester check?

Are the required headers present?
Is the token valid?
Does the API reject missing or invalid authentication when required?
Does the server handle unsupported media types correctly?
Does the API return an appropriate response for unsupported formats?

Important: Not every endpoint requires every header. Follow the API specification.

5. Request Body

The request body contains data sent to the server, commonly when creating or updating a resource.

Example: A request to create a new product might contain this JSON body.

{  "name": "Wireless Mouse",  "price": 799,  "category": "Electronics"}

The request body contains three fields: name, price, and category.

What should a tester check?

Are all mandatory fields included?
Are field values correct?
Are the data types valid?
Are invalid values rejected?
Are additional fields accepted or rejected according to the contract?
Does the API save the submitted data correctly?

Real-time scenario: If the product price is submitted as a negative number and negative prices are prohibited by the requirements, the API should return the specified validation error.

6. Response Body

The response body contains the data or message returned by the API.

Example:

{  "id": 101,  "name": "Wireless Mouse",  "price": 799,  "category": "Electronics"}

After sending a request to create a product, the API might return the newly created product details.

What should a tester check?

Are all expected fields present?
Are field values correct?
Are data types correct?
Is the returned data consistent with the request?
Is sensitive information excluded?
Does the response match the documented structure?

Example defect: The request creates a product priced at 799, but the response shows 7999. This is a data correctness issue.

7. Response Headers

Response headers provide information about the server’s response.

Example:

HTTP/1.1 200 OKContent-Type: application/jsonCache-Control: no-store

Common response headers include:

Content-Type — identifies the response body’s media type.
Cache-Control — specifies caching rules.
Set-Cookie — may instruct a client to store a cookie.
Location — may identify a resource created or redirected to.
Access-Control-Allow-Origin — provides a CORS policy value when applicable.

What should a tester check?

Is the content type correct?
Are required security-related headers present?
Are caching rules appropriate for the data?
Is a Location header correct when the API contract requires one?
Are CORS headers appropriate for browser-based clients?

Header requirements depend on the API and its security design.

8. Response Status Code

An HTTP status code indicates the outcome of a request.

Status code	Simple meaning
`200 OK`	Request succeeded
`201 Created`	A resource was created
`204 No Content`	Request succeeded with no response body
`400 Bad Request`	Request is invalid
`401 Unauthorized`	Authentication is missing or invalid
`403 Forbidden`	Access is not permitted
`404 Not Found`	Resource or endpoint was not found
`405 Method Not Allowed`	HTTP method is not supported for that resource
`409 Conflict`	Request conflicts with the current resource state
`415 Unsupported Media Type`	Request media type is unsupported
`422 Unprocessable Content`	Request content cannot be processed according to the API’s validation rules
`429 Too Many Requests`	Rate limit was exceeded
`500 Internal Server Error`	Unexpected server error
`503 Service Unavailable`	Service is temporarily unavailable

Testing example: When creating a product, verify that a successful creation returns the documented success code, often 201. Do not assume every successful API must return 200.

A response status code must be checked against the endpoint’s documented behavior.

9. Response Time

Response time is the time taken for an API request to receive a response.

For example, if a product search request takes 250 milliseconds, its measured response time is approximately 250 ms in that test run.

Why is it important?

Slow APIs can affect user experience.
Delays can cause timeouts.
High traffic can expose performance problems.
Response time can help identify performance regressions.

Test scenarios:

Check normal response time.
Run repeated requests to observe consistency.
Compare results with the documented performance target.
Test under expected load using an appropriate performance-testing tool.

Example: If the agreed target is that 95% of requests complete within 500 ms under specified test conditions, measure whether the API meets that target. A single fast request does not prove that the API meets the performance requirement.

10. Content-Type and Accept Headers

These headers serve different purposes.

Content-Type tells the server or client what format the current message body uses.

Accept tells the server which response media types the client can accept.

Example:

Content-Type: application/jsonAccept: application/json

Content-Type: application/json means the request body is JSON.
Accept: application/json means the client accepts a JSON response.

Testing example: Send JSON to an endpoint that expects JSON, then test what happens when an unsupported content type is sent.

Possible checks:

Correct content type.
Missing content type where required.
Unsupported content type.
Unsupported Accept value.
Response format matches the requested and documented format.

Do not confuse these headers: one describes the message body; the other expresses the preferred response format.

11. JSON Objects and Arrays

JSON is a commonly used format for API request and response data.

A JSON object contains key-value pairs enclosed in curly braces {}.

{  "id": 101,  "name": "Mouse",  "price": 799}

A JSON array contains a list of values enclosed in square brackets [].

[  {    "id": 101,    "name": "Mouse"  },  {    "id": 102,    "name": "Keyboard"  }]

In the second example, the response contains an array of two product objects.

What should a tester check?

Is the JSON valid?
Is an object returned where an object is expected?
Is an array returned where a list is expected?
Does each array item have the expected structure?
Are the values and data types correct?
Is an empty array handled correctly when no records match?

An empty array [] can be a valid response. It does not automatically mean that the API has failed.

12. Mandatory and Optional Fields

Mandatory fields must be provided when the API contract requires them. Optional fields may be omitted.

Example:

{  "name": "Wireless Mouse",  "price": 799,  "description": "Wireless USB mouse"}

Suppose name and price are mandatory, while description is optional.

Test scenarios:

Send all required fields.
Remove name.
Remove price.
Omit description.
Send an empty value for a mandatory field.
Verify the documented validation response.

Expected result: The API should accept valid requests and reject missing mandatory information according to the specification.

Remember that an optional field can still have validation rules if it is supplied.

13. Data Types and Field Values

Data types define what kind of value a field is allowed to contain.

Common JSON data types:

Type	Example
String	`"name": "Rahul"`
Number	`"price": 799`
Integer	`"quantity": 3`
Boolean	`"available": true`
Object	`"address": {"city": "Pune"}`
Array	`"skills": ["Java", "SQL"]`
Null	`"middleName": null`

JSON has a general number type; integer is a value convention or schema constraint rather than a separate JSON primitive type.

Testing example: If quantity must be a non-negative integer, test values such as 3, 0, -1, "three", and 3.5 against the documented rules.

Check both the data type and business rules. A value can have the correct type but still be invalid.

14. Null, Empty and Missing Fields

These three situations are different and are important in API testing.

Consider these examples.

Null field:

{  "middleName": null}

The field exists, but it has no assigned value.

Empty string:

{  "middleName": ""}

The field exists and contains a string with zero characters.

Missing field:

{  "firstName": "Rahul"}

The middleName field is not included.

Empty array:

{  "orders": []}

The orders field exists, but the list contains no items.

What should a tester check?

Is the field mandatory?
Is null permitted?
Is an empty string permitted?
Can the field be omitted?
Does an empty array mean no records were found?
Does the API handle each case according to its contract?

A common defect occurs when the API treats a missing field and a null field as equivalent even though the business rules require different behavior.

15. Nested JSON Validation

Nested JSON means that an object or array is present inside another JSON object.

Example:

{  "id": 101,  "name": "Rahul",  "address": {    "city": "Pune",    "state": "Maharashtra"  }}

Here, address is a nested object containing city and state.

A more complex response could contain an array of orders, each with its own nested product details.

What should a tester check?

Is the parent object present?
Are the nested fields present?
Are the nested values correct?
Are the nested data types correct?
Does the array contain the expected records?
Are nested fields handled correctly when absent or null?

Example defect: The response returns the correct customer name but the wrong city in the nested address object.

The top-level response may look correct, but nested validation can reveal the defect.

16. Error Message Validation

Error message validation checks whether an API returns the correct error response when something goes wrong.

Example:

{  "error": "VALIDATION_ERROR",  "message": "Email is required"}

Test scenarios:

Missing required field.
Invalid email format.
Invalid resource ID.
Invalid authentication token.
Insufficient permissions.
Duplicate record.
Unsupported HTTP method.
Invalid request body.

What should a tester check?

Is the status code correct?
Is the error message meaningful?
Is the error code correct?
Does the response follow the documented structure?
Does it avoid exposing internal implementation details or sensitive data?

Example: If an invalid email is submitted, the API should return the documented validation error rather than an unexpected server error.

Do not test only the error message. Validate the status code and the complete error response as well.

17. Date, Time and Format Validation

APIs often exchange dates and times for bookings, payments, deliveries, and other business operations.

Example:

{  "bookingDate": "2026-11-15",  "createdAt": "2026-11-15T10:30:00Z"}

bookingDate represents a date.
createdAt represents a timestamp, with Z indicating UTC.

What should a tester check?

Is the date in the expected format?
Is the date valid?
Is the time zone handled correctly?
Are past and future dates allowed according to business rules?
Are leap years handled correctly?
Is the returned time consistent with the documented time zone?
Are invalid dates rejected appropriately?

Example: If a booking API requires YYYY-MM-DD, test a valid date such as 2026-11-15 and invalid formats such as 15/11/2026.

Also test invalid calendar dates, such as 31 February, if the API accepts date input.

A date can have the correct format but still be invalid, so check both format and actual date validity.

18. Response Schema Validation

A response schema defines the expected structure, data types, and constraints of an API response.

For example, a product response might be expected to contain:

id — integer.
name — string.
price — number.
available — boolean.

Example response:

{  "id": 101,  "name": "Wireless Mouse",  "price": 799,  "available": true}

Schema validation checks whether the actual response matches the defined rules.

What should a tester check?

Are required fields present?
Are field data types correct?
Are unexpected fields allowed?
Are numeric limits and string constraints satisfied?
Are nested objects and arrays correct?
Are null values permitted?
Does the response follow the API specification?

Example defect: The API returns "price": "799" as a string instead of "price": 799 as a number, even though the schema requires a number.

Schema validation is useful because it can detect structural problems across many test cases without manually checking every field.

Practical API Testing Example

Suppose you are testing this endpoint:

GET https://api.shopdemo.com/products/101

Expected response:

{  "id": 101,  "name": "Wireless Mouse",  "price": 799,  "available": true}

API Testing Full Notes PDF for QA

1. What is an API?

2. What is API Testing?

3. Why Do We Need API Testing?

4. What Is the Purpose of API Testing?

Module 4: HTTP Methods

Module 5: HTTP Status Codes

5. What Is an API in Simple Terms?

6. Real-World Examples of APIs

7. How APIs Work

8. Client-Server Architecture

9. Request and Response Cycle

10. What Is an API Endpoint?

11. What Is an API URL?

12. What Is an API Contract?

13. What Is an API Specification?

14. What Is an API Provider and API Consumer?

15. What Is an API Gateway?

16. What Is API Integration?

17. API Testing vs UI Testing

18. API Testing vs Unit Testing

19. API Testing vs Integration Testing

20. Advantages and Limitations of API Testing

Advantages

Limitations

21. When Should API Testing Be Performed?

22. Role of an API Tester in a Software Project

Quick Revision for Beginners

Module : Positive and Negative Testing

Module : CRUD Operations — Real-Time Functionality

Module : Most Important Interview Scenarios

5. How do you test a DELETE API?

Module : Request and Response Validation

1. Base URL and Endpoint

2. Path Parameters

3. Query Parameters

4. Request Headers

5. Request Body

6. Response Body

7. Response Headers

8. Response Status Code

9. Response Time

10. Content-Type and Accept Headers

11. JSON Objects and Arrays

12. Mandatory and Optional Fields

13. Data Types and Field Values

14. Null, Empty and Missing Fields

15. Nested JSON Validation

16. Error Message Validation

17. Date, Time and Format Validation

18. Response Schema Validation

Practical API Testing Example

Leave a Comment Cancel Reply