Test Cases for API Testing – How to Write & Example

What Are API Test Cases?

An API (Application Programming Interface) is the communication layer between software services. It allows a frontend application, mobile app, or third-party service to request data or trigger actions from a backend system.

API test cases are documented scenarios that validate this communication. Each test case sends a specific HTTP request to an API endpoint and verifies that the response matches expected behavior across four dimensions:

Dimension	What It Validates
Status Code	Did the server respond correctly? (200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 404 Not Found, 500 Internal Server Error)
Response Body	Does the response JSON/XML contain correct fields, data types, and values?
Response Headers	Are Content-Type, Authorization, and other headers present and correct?
Response Time	Did the server respond within the acceptable performance threshold?

Why Are API Test Cases Important?

The scale of modern API usage makes thorough API testing non-negotiable:

• The average modern application uses 26 to 50 APIs to function (Postman State of the API, 2024). If one fails, it can cascade across the entire app.
• The API testing market was valued at $2.32 billion in 2024, growing at 20.9% CAGR to reach $10.59 billion by 2032 (SNS Insider, 2025), reflecting how critical API quality has become.
• 83% of all public APIs use REST API testing architecture as of 2024 (RapidAPI Developer Survey).
• 39% of developers cite inconsistent API documentation as their biggest collaboration obstacle (Postman State of the API, 2024).
• APIs are tested before the UI exists. API test cases catch bugs at a fraction of the cost, with defects found in production costing significantly more than those caught during development (IBM Systems Sciences Institute).

Why API test cases specifically (vs. exploratory testing):

• Repeatability: Documented test cases produce the same steps and checks on every run, so any change in API behavior shows up immediately as a regression.
• Coverage: A systematic approach makes sure every endpoint is checked across HTTP methods, expected status codes, error responses, and edge cases like empty payloads or invalid auth tokens.
• Earlier bug detection: Catching API defects during development is far cheaper than fixing them after release, when they may already affect integrations, clients, and end users.
• CI/CD readiness: Well-defined test cases convert easily into automated suites that run on every commit or pull request, blocking broken builds before they merge.
• Living documentation: Test cases show exactly how the API is expected to behave, giving developers and new team members an up-to-date reference that stays in sync with the code.

What is the Standard API Test Case Format?

A well-structured API test case contains nine fields. Use this as your baseline template for every API test:

Field	Description	Example
Test Case ID	Unique identifier	TC_API_001
Test Case Title	Descriptive name	Verify GET /users returns 200 with user list
Description	What is being validated	Checks that the users endpoint returns a valid list with all required fields
Preconditions	Setup requirements	API server running; test database populated with 5 users
HTTP Method	Request type	GET
Endpoint URL	Full request URL	https://api.example.com/v1/users
Headers	Request headers	Content-Type: application/json, Authorization: Bearer {token}
Request Body	Payload (POST/PUT/PATCH/DELETE)	{“name”: “Test User”, “email”: “test@example.com”}
Expected Status Code	HTTP response code	200 OK
Expected Response Body	JSON/XML structure expected	[{“id”: 1, “name”: “…”, “email”: “…”}]
Expected Headers	Response headers expected	Content-Type: application/json
Actual Result	Filled during execution
Pass/Fail	Based on expected vs actual	Pass / Fail
Notes	Dependencies or observations	Depends on TC_API_000 (auth token setup)

How Do You Write API Test Cases Step by Step?

Here’s a step-by-step process for writing structured, reliable API test cases from scratch.

Step 1: Understand the API Specification

Before writing a single test case, read the API documentation (OpenAPI/Swagger, Postman collection, or internal specs). Identify every endpoint, HTTP method, required parameters, authentication mechanism, and expected responses for both success and error scenarios.

Step 2: Define What to Test First

Prioritize in this order:

• Happy path: valid inputs producing successful responses (200, 201)
• Negative cases: invalid inputs producing the correct error responses (400, 401, 403, 404)
• Boundary conditions: values at the edge of allowed ranges
• Security: authentication bypass attempts, injection payloads
• Performance: response time under load

Step 3: Use a Consistent Naming Convention

Test case titles should follow: [HTTP Method] [Endpoint] [Scenario]

Examples:

• GET /users – Returns 200 with valid auth token
• POST /users – Returns 400 for missing required email field
• DELETE /users/{id} – Returns 404 for non-existent user ID

Step 4: Write the Test Case Using the 9-Field Format

Fill in all 9 fields for every test case. Leave no field empty. “Preconditions” is the most commonly skipped field and the most common cause of environment-related failures.

Step 5: Cover All HTTP Status Code Categories

For every endpoint, write at least one test case for each applicable status code category:

Status Code Category	Example Codes	Test Scenario
2xx Success	200, 201, 204	Valid request producing correct success response
4xx Client Error	400, 401, 403, 404, 409, 422, 429	Invalid/missing input, unauthorized access, resource not found
5xx Server Error	500, 502, 503	Server-side failures, gateway errors

Step 6: Parameterize for DATA-Driven Coverage

Instead of writing separate test cases for each user type, parameterize with a data table:

Username	Password	Expected Status	Expected Response
valid@test.com	GoodPass1!	200	{“token”: “…”}
invalid@test.com	WrongPass	401	{“error”: “Invalid credentials”}
(empty)	GoodPass1!	400	{“error”: “Email is required”}
valid@test.com	(empty)	400	{“error”: “Password is required”}

Step 7: Integrate into CI/CD

Automate your API test cases and trigger them on every pull request. API tests are fast (50 to 200 tests per minute depending on complexity), so there is no reason to run them only on a schedule. Learn more about how testing fits into your CI/CD pipeline to get the most out of automation.

What Are the 6 Categories of API Test Cases?

Every API test case falls into one of six categories, each targeting a different layer of API reliability.

Category 1: Functional API Test Cases

Functional API testing verifies that each endpoint does exactly what it is supposed to do.

Test Case ID	Title	Method	Endpoint	Expected Status	Expected Result
TC_FUNC_001	Valid GET returns 200 with all users	GET	/users	200	JSON array of user objects with id, name, email fields
TC_FUNC_002	POST creates new user, returns 201	POST	/users	201	Created user object with new id; Location header present
TC_FUNC_003	PUT updates existing user, returns 200	PUT	/users/1	200	Updated user object with new field values
TC_FUNC_004	PATCH partially updates user, leaves other fields unchanged	PATCH	/users/1	200	Only specified fields updated; other fields unchanged
TC_FUNC_005	DELETE removes user, returns 204	DELETE	/users/1	204	No response body; user no longer retrievable
TC_FUNC_006	GET returns 404 for non-existent resource	GET	/users/99999	404	{“error”: “User not found”}
TC_FUNC_007	Response body contains all required fields	GET	/users/1	200	id, name, email, created_at fields all present
TC_FUNC_008	Response data types are correct	GET	/users/1	200	id is integer, name and email are strings
TC_FUNC_009	CRUD end-to-end flow works in sequence	POST, GET, PUT, DELETE	/users	201, 200, 200, 204	Each operation succeeds; data reflects each change

Category 2: Security API Test Cases

Security tests verify that the API correctly enforces authentication, authorization, and input validation.

Test Case ID	Title	Method	Scenario	Expected Status	Expected Result
TC_SEC_001	Request with no auth token returns 401	GET	No Authorization header	401	{“error”: “Unauthorized”}
TC_SEC_002	Request with expired token returns 401	GET	Expired Bearer token	401	{“error”: “Token expired”}
TC_SEC_003	User A cannot access User B’s private data	GET	Valid token for User A; request /users/B	403	{“error”: “Forbidden”}
TC_SEC_004	SQL injection in request parameter is rejected	GET	/users?id=1′ OR ‘1’=’1	400	Error or empty result; no SQL data leaked
TC_SEC_005	XSS payload in request body is sanitized	POST	{“name”: “”}	400 or 201	Script tags stripped or rejected
TC_SEC_006	Sensitive data is not exposed in error messages	GET	/users/invalid	404	No stack trace, DB connection strings, or internal paths
TC_SEC_007	Rate limiting returns 429 after threshold	GET	200+ requests in 1 minute	429	{“error”: “Too many requests”} with Retry-After header
TC_SEC_008	Data transmitted via HTTPS only	GET	HTTP (non-secure) request	301 or connection refused	Redirected to HTTPS or rejected
TC_SEC_009	API key or token not exposed in responses	GET	Any authenticated request	200	Response body contains no auth credentials

Category 3: Performance API Test Cases

API performance testing verifies that the API responds within acceptable time thresholds under normal and peak loads.

Test Case ID	Title	Condition	Metric	Pass Threshold
TC_PERF_001	Response time under normal load	1 concurrent user	Time to first byte	< 200ms
TC_PERF_002	Response time under moderate load	50 concurrent users	Average response time	< 500ms
TC_PERF_003	Response time under peak load	500 concurrent users	95th percentile response time	< 2000ms
TC_PERF_004	Throughput measurement	60 seconds	Requests per second	≥ 100 RPS
TC_PERF_005	Scalability under increasing load	100, 500, 1000 users	Degradation rate	< 20% increase in response time
TC_PERF_006	Stress test to find breaking point	Continuously increase load	Error rate threshold	< 1% error rate at target load
TC_PERF_007	Rate limit header present in responses	Any request	X-RateLimit-* headers	Present and accurate

Category 4: Regression API Test Cases

Regression tests ensure that new code changes do not break existing API behavior.

Test Case ID	Title	Verification Approach
TC_REG_001	Existing endpoints return same response schema after update	Compare JSON schema of responses before and after deployment
TC_REG_002	New API version does not break v1 consumers	Run v1 test suite against new build
TC_REG_003	All functional tests pass after code change	Re-execute TC_FUNC_001 through TC_FUNC_009
TC_REG_004	API integrations with dependent services still work	End-to-end integration test across service boundaries
TC_REG_005	Automated regression suite completes without new failures	Run full automated suite; 0 new failures introduced

Category 5: Usability API Test Cases

Test Case ID	Title	What to Check
TC_USE_001	API documentation matches actual behavior	Send requests as documented; verify documented responses match actual
TC_USE_002	Consistent naming conventions across endpoints	All endpoints use the same naming style (snake_case, camelCase)
TC_USE_003	Error messages are actionable	Error responses include field name and specific issue
TC_USE_004	API is easy to integrate (clear auth flow)	Complete auth to first successful request in < 5 minutes

Category 6: Compliance API Test Cases

Test Case ID	Title	Standard	What to Check
TC_COMP_001	PII data masked in logs	GDPR / HIPAA	Request/response logs do not contain full SSN, passwords, card numbers
TC_COMP_002	Data retention policy enforced via API	GDPR Article 17	DELETE endpoint actually removes data from persistence layer
TC_COMP_003	API requires consent for data collection	GDPR	Relevant endpoints check for user consent before processing
TC_COMP_004	Audit log records all data access	SOC 2 / HIPAA	Every GET on sensitive resource creates an audit log entry

What Does a Complete API Test Case Template Look like?

Here are two ready-to-use API test case templates you can copy and adapt for your own projects.

Example: Google Oauth Login API Test Case

The following 3-case table covers a common real-world scenario, testing third-party authentication:

Sl.No	Test Case Title	Priority	HTTP Method	Endpoint	Request Payload	Expected Status	Expected Response	Pass/Fail
TC_API_001	Login with valid Google credentials	High	POST	/auth/google	{“token”: “<valid_google_token>”}	200	{“access_token”: “…”, “user”: {“id”: …, “email”: “…”}}	–
TC_API_002	Login with invalid/expired Google token	High	POST	/auth/google	{“token”: “<expired_token>”}	401	{“error”: “Invalid or expired token”}	–
TC_API_003	Login without providing a token	High	POST	/auth/google	{}	400	{“error”: “token is required”}	–

Example: Response Header Validation Test Case

Field	Value
Test Case ID	TC_API_010
Title	Verify Content-Type header is application/json for GET /users
Method	GET
Endpoint	/users
Headers (Request)	Authorization: Bearer {valid_token}
Expected Status	200
Expected Response Header	Content-Type: application/json; charset=utf-8
Expected Body	JSON array of user objects
Pass Criteria	Status is 200 AND Content-Type header matches exactly

Download the full template: API Testing Test Case Template (Google Sheets)

How Do You Automate API Test Cases with Testsigma?

Testsigma provides a codeless API testing platform that lets you create, execute, and manage API test cases without writing code. It integrates directly with Postman collections, Swagger/OpenAPI specs, and CI/CD pipelines.

Documentation:

• Getting Started: Automate REST APIs
• REST API Test Step Type
• API Request Configuration

Step 1: Log in and Open Test Management

Log in to app.testsigma.com. Navigate to the Test Cases tab and create a new folder named for your API (e.g., “User Authentication API”).

Step 2: Generate API Test Cases Using AI (generator Agent)

Click Ask AI and provide a prompt describing your API:

• “Generate test cases for a login API that accepts email and password via POST /auth/login”
• “Generate test cases for the GET /users endpoint including 200, 401, and 404 scenarios”

Alternatively, import directly from:

• Postman: export collection as JSON and upload to Testsigma
• Swagger/OpenAPI: upload your .yaml or .json spec file
• Jira: generate test cases from linked requirements

Step 3: Create an API Test Case Manually

For custom test cases, click Create Test Case and choose Step Type: REST API.

Enter:

• Title (e.g., “GET /users – Returns 200 with valid token”)
• HTTP Method: select from GET, POST, PUT, PATCH, DELETE
• Endpoint URL (e.g., https://api.example.com/v1/users)
• Headers: add key-value pairs (Authorization: Bearer {{auth_token}})
• Request Body: for POST/PUT/PATCH, enter JSON payload
• Assertions: add codeless verifications such as Status Code = 200, Response Body contains “id”, Content-Type header = application/json

Step 4: Add Assertions for Each Validation Point

In Testsigma, assertions validate the response without any code. Click Add Verification and configure:

Assertion Type	Example
Status Code	Expected: 200
Response Body (Contains Field)	data[0].id exists
Response Body (Field Value)	data[0].email equals “test@example.com”
Response Header	Content-Type equals application/json
Response Time	Less than 500ms
JSON Schema	Upload expected schema file

Step 5: Create a Test Run and Execute

Navigate to Test Runs, then Create Test Run. Select your API test cases and click Execute with Atto.

Atto (Testsigma’s execution AI agent) executes each test, validates assertions automatically, and generates results with:

• Pass/Fail status per assertion
• Full request and response logs
• Response time metrics
• AI-generated failure analysis with suggested fixes

Step 6: Integrate with CI/CD

Trigger API test runs automatically from Jenkins, GitHub Actions, Azure DevOps, or CircleCI. Testsigma provides REST API and webhook triggers to start runs from your pipeline.

Example GitHub Actions trigger:

- name: Run API Test Suite
  run: |
    curl -X POST "https://app.testsigma.com/api/v1/execution_results" \
      -H "Authorization: Bearer ${{ secrets.TESTSIGMA_API_KEY }}" \
      -d '{"test_plan_id": "123"}'

Testsigma Automated API Testing: testsigma.com/automated-api-testing

What Are Generic API Test Cases Every API Should Have?

Regardless of your application, these test cases apply to virtually every REST API:

• Validate API keys for minimum and maximum length/range
• Verify JSON and XML response formats match the API contract testing
• Validate JSON schema, correct field types, and mandatory fields present
• Verify response headers match expected Content-Type, Cache-Control, and CORS headers
• Validate HTTP status codes for all major success and error scenarios
• Test request chaining with multiple APIs working together in sequence
• Verify CRUD operations end-to-end (Create, Read, Update, Delete)
• Test boundary values, maximum/minimum allowed parameter values
• Test for empty, null, and missing required parameters
• Verify database integrity and data persisted correctly after write operations
• Validate error messages are descriptive and actionable
• Test file upload endpoints if applicable
• Verify rate limiting is enforced and documented correctly
• Test pagination with correct page sizes, page counts, and navigation

Conclusion

API test cases are the foundation of reliable software. When every endpoint is validated for correct status codes, response bodies, headers, and error handling across functional, security, performance, regression, usability, and compliance scenarios, you catch defects early, ship faster, and protect the user experience.

The key is consistency: use a standardized test case format, cover all six categories, automate everything, and run your suite on every commit. Start with the test cases and templates in this guide, then scale with automation as your API surface grows.

FAQs