60 Test Cases For API Testing For Each Category

APIs carry the load of modern enterprise software. Every customer journey moves through them, every integration depends on them, and every release puts new ones into production. Designing solid test cases is the difference between catching defects in staging and discovering them through customer support tickets.

Below are 50 categorised test cases covering functional, performance, security, and contract testing, followed by a design guide.

What an API Test Case Actually Looks Like

An API test case is a structured specification of how an endpoint should behave under a defined set of conditions. The shape is consistent regardless of language or platform.

A complete test case includes:

• Preconditions: The system state, authentication tokens, seeded data, and environment configuration required before the request fires
  ‍
• The request itself: HTTP method, endpoint, headers, query parameters, path variables, and request body
  ‍
• Expected response: Status code, headers, body schema, specific values, and timing expectations
  ‍
• Postconditions: Any system state changes the call should produce, including database mutations and downstream events
  ‍

A test case missing any of these elements is incomplete. The most common gap is postcondition validation. A successful HTTP 201 response means the API accepted the call. It does not prove the resource was actually persisted, replicated, or made visible to consumers.

60 Test Cases For API Testing For Each Category

1. Functional Test Cases for API Testing

Functional testing validates that each endpoint does what it claims to do. These cases cover the core operations every API suite must address before moving into edge cases and security scenarios.

✅ Valid GET request returns HTTP 200 with the expected response body‍

Send a GET request to a valid endpoint with correct authentication. The response should return HTTP 200 with the full resource payload. Assert that all contracted fields are present, no fields are missing, and the values match what is stored in the database.

✅ Valid POST request returns HTTP 201 with the created resource

‍Send a POST request with a well-formed payload and valid authentication. The response should return HTTP 201 with the newly created resource including its generated ID. Verify the resource now exists in the database with the correct field values and timestamps.

✅ Valid PUT request updates the resource and returns HTTP 200‍

Send a PUT request with updated field values for an existing resource. The response should return HTTP 200 with the updated resource. Query the database directly to confirm the changes were persisted and that unchanged fields were not overwritten.

✅ Valid DELETE request removes the resource and returns HTTP 204‍

Send a DELETE request for an existing resource. The response should return HTTP 204 with no response body. Follow up with a GET request using the same ID and confirm the response returns HTTP 404, proving the resource is no longer accessible.

✅ Valid PATCH request partially updates the resource‍

Send a PATCH request updating only one field of an existing resource while leaving all other fields unchanged. The response should return HTTP 200 with the updated resource. Verify the patched field changed and all other fields remain exactly as they were before the request.

✅ Pagination returns the correct page with accurate metadata‍

Send a GET request with page and page size parameters. Verify the response contains exactly the expected number of items, the items correspond to the correct page of the dataset, and pagination metadata such as total count, current page, and next page link are accurate.

✅ Sorting parameter returns results in the correct order

‍Send a GET request with a sort parameter specifying ascending order on a date field. Verify all items in the response are ordered correctly from earliest to latest. Repeat with descending order and verify the reversal. This confirms sort logic is applied correctly rather than returning results in insertion order.

✅ Filtering parameter returns only matching results with no extras‍

Send a GET request with a filter parameter such as status=active. Verify every item in the response matches the filter condition and no items with a different status appear. Also verify the total count in the metadata reflects the filtered set, not the full dataset.

✅ Response body matches the published OpenAPI schema‍

Send a valid request and capture the response body. Validate it programmatically against the published JSON Schema or OpenAPI specification. Every required field must be present, every field type must match the contract, and no additional undocumented fields should appear in the response.

✅ Response time is within the documented latency threshold

‍Send a valid GET request and measure the time between the request being sent and the response being received. Verify this falls within the maximum latency documented in the API specification or SLA. Repeat this ten times and verify none of the responses exceed the threshold, not just the average.

✅ API returns correct results when optional fields are omitted‍

Send a POST request with only the required fields and no optional fields. The response should return HTTP 201 and the resource should be created successfully. Retrieve the resource and verify optional fields either contain default values as specified or are absent from the response rather than causing errors.

✅ API returns correct results when all optional fields are included‍

Send a POST request with all required and optional fields populated. The response should return HTTP 201 and all field values should be stored and returned exactly as submitted. This case confirms the API does not silently ignore or strip optional fields.

2. Test Cases for API Authentication Testing

Authentication confirms who the caller is. These cases verify the API correctly identifies callers and rejects requests that cannot be verified.

✅ Valid bearer token is accepted and returns the expected resource‍

Send a request with a correctly formatted, unexpired bearer token in the Authorization header. The response should return the expected resource with HTTP 200. This is the baseline that confirms the authentication mechanism is working before testing the failure cases.

✅ Expired token returns HTTP 401 with the correct WWW-Authenticate header‍

Generate or simulate an expired token and send it in the Authorization header. The response should return HTTP 401. Verify the WWW-Authenticate header is present and the error body indicates the token has expired rather than being invalid. This distinction matters for consumers implementing automatic token refresh.

✅ Malformed token returns HTTP 401 without exposing parsing details‍

Send a request with a deliberately corrupted token such as a truncated JWT or a token with an invalid signature. The response should return HTTP 401. Verify the error body does not expose how the token was parsed, what algorithm is expected, or any internal authentication mechanism details.

✅ Missing Authorization header returns HTTP 401 consistently across all endpoints‍

Send a request to a protected endpoint with no Authorization header. The response should return HTTP 401. Run this test against every protected endpoint in the API, not just one, to confirm the authentication middleware is applied uniformly rather than selectively.

✅ Refresh token flow produces a new valid access token‍

Send a request to the token refresh endpoint with a valid refresh token. The response should return a new access token with an updated expiry time. Verify the new access token works correctly by using it to access a protected resource. Also verify the original access token behaviour matches the contract.

✅ API key passed in a query parameter is rejected‍

Attempt to authenticate by passing an API key as a query parameter such as ?api_key=value rather than in the Authorization header. The response should return HTTP 401, confirming credentials are only accepted through the documented header. Accepting credentials in URLs risks them being logged in server access logs and browser history.

3. Test Cases for API Authorisation Testing

Authorisation confirms what an authenticated caller is permitted to do. These cases verify that access controls are correctly enforced across roles, tenants, and permission scopes.

✅ Role without write permission cannot create or modify resources‍

Authenticate with a token belonging to a read-only role. Attempt POST, PUT, and DELETE requests. Each should return HTTP 403 with an error message indicating the caller lacks the required permission. Verify no partial writes occurred by checking the database state after each attempt.

✅ Cross-tenant resource access returns HTTP 404 not HTTP 403‍

Authenticate as a valid user in tenant A and attempt to access a resource belonging to tenant B using its known ID. The response should return HTTP 404 rather than HTTP 403. Returning HTTP 403 would confirm to the caller that the resource exists but is inaccessible. Returning HTTP 404 prevents resource enumeration by unauthorised parties.

✅ OAuth token without the required scope returns HTTP 403

‍Generate a valid OAuth token missing the scope required for the operation being tested, for example a token with orders:read but not orders:write. Attempt to send a POST request. The response should return HTTP 403. Verify the error body identifies the missing scope requirement.

✅ Read-only token cannot execute write operations on any endpoint‍

Authenticate with a token that has read-only permissions. Attempt POST, PUT, and DELETE requests on all endpoints that require write access. Each should return HTTP 403. Verify the database state is unchanged after each attempt to confirm no writes occurred despite the rejected responses.

✅ Administrative endpoints are inaccessible to standard user tokens

‍Identify all administrative endpoints in the API such as user management, configuration, and reporting. Authenticate as a standard user and attempt to access each one. Every request should return HTTP 403. Document which endpoints were tested and the tokens used so the test case can be reproduced reliably.

✅ JWT signature validation rejects tampered tokens

‍Take a valid JWT and modify the payload section to escalate privileges such as changing a role claim from user to admin. Send the modified token with the original signature. The response should return HTTP 401 because the signature no longer matches the payload. This confirms the API validates the full token rather than just decoding the claims.

4. Test Cases for API Negative and Boundary Testing

Negative and boundary cases are where the most impactful defects hide. Most production incidents involving API validation trace back to boundaries that were never explicitly tested.

✅ Field value at the minimum boundary is accepted and stored correctly‍

Send a request where a constrained numeric field contains exactly the minimum valid value. For a field accepting values from 1 to 100, send 1. The response should return the expected success code and the value should be stored correctly. This confirms the minimum boundary is inclusive and correctly implemented.

✅ Field value one below the minimum is rejected with HTTP 400‍

Send a request where a constrained field contains a value one unit below the minimum, for example 0 for a field accepting 1 to 100. The response should return HTTP 400 with a validation error identifying the field and the violated constraint. Verify no partial processing occurred.

✅ Field value at the maximum boundary is accepted and stored correctly‍

Send a request where a constrained field contains exactly the maximum valid value, for example 100 for a field accepting 1 to 100. The response should return the expected success code. This confirms the maximum boundary is inclusive and correctly implemented. A common defect here is using a strict less-than operator instead of less-than-or-equal-to.

✅ Field value one above the maximum is rejected with HTTP 400

‍Send a request where a constrained field contains a value one unit above the maximum, for example 101 for a field accepting 1 to 100. The response should return HTTP 400 with a validation error. This case specifically catches off-by-one errors at the upper boundary.

✅ Empty string in a required field returns HTTP 400‍

Send a POST or PUT request where a required text field is present in the payload but contains an empty string. The response should return HTTP 400 identifying the field. Some implementations incorrectly treat an empty string as a valid value for a required field, which this test case detects.

✅ Null value in a required field returns HTTP 400 with the field name‍

Send a request where a required field is explicitly set to null in the JSON payload. The response should return HTTP 400 with the field name clearly identified in the error. Verify the error distinguishes between a null value and a missing field, as these represent different client errors.

✅ Special characters in text fields are processed safely without server errors

‍Send a request where text fields contain special characters including apostrophes, quotation marks, angle brackets, ampersands, and backslashes. The response should either accept the input and store it correctly, or reject it with HTTP 400 if the characters violate validation rules. A HTTP 500 response to special character input indicates a server-side handling defect.

✅ Excessively large request body returns HTTP 413 with a clear error‍

Send a POST request with a payload significantly larger than the documented maximum. The response should return HTTP 413 Payload Too Large with an error message indicating the limit. Verify the server does not crash, time out, or return HTTP 500 in response to the oversized payload.

✅ Wrong Content-Type header returns HTTP 415‍

Send a POST request with a JSON payload but set the Content-Type header to text/plain or application/xml. The response should return HTTP 415 Unsupported Media Type rather than attempting to parse the body incorrectly. This confirms the API validates the content type before processing the request.

✅ Malformed JSON body returns HTTP 400 not HTTP 500

‍Send a POST request with syntactically invalid JSON in the body such as a missing closing brace or an unquoted key. The response should return HTTP 400 with a parsing error message. A HTTP 500 response to malformed JSON indicates the error is not being caught gracefully before it reaches application logic.

5. Test Cases for API Error Handling

Error responses need to be as precisely specified as success responses. Downstream consumers often branch their logic on error codes, and a regression in error shape causes silent failures across an integration network.

✅ Every error response follows the contracted error schema‍

Trigger each category of error: validation failure, authentication failure, not found, and server error. For each, validate the response body against the documented error schema. Every field in the error schema should be present and correctly typed. An error response that deviates from the schema is a contract violation that will break consumers silently.

✅ Stack traces and internal paths are never exposed in error responses‍

Deliberately trigger server-side errors by sending requests designed to cause exceptions such as database constraint violations or null pointer conditions. Inspect every error response for stack traces, file paths, class names, framework version strings, or internal service URLs. None of these should appear in any response returned to the caller.

✅ Internal server errors return HTTP 500 with a support reference ID‍

Trigger a genuine server error and verify the response returns HTTP 500 with a reference ID that support teams can use to locate the relevant logs. The response should not contain the underlying error message or exception type. The reference ID should be unique per request so the specific failure can be traced.

✅ Validation errors identify the specific field and constraint that failed

‍Send a request that fails multiple validation rules simultaneously such as a missing required field and a value exceeding the maximum length. Verify the error response lists each failing field separately with the specific constraint violated. A single generic error message is not sufficient for a consumer to correct the request without trial and error.

✅ Rate limit exceeded returns HTTP 429 with a Retry-After header‍

Send requests at a rate exceeding the documented rate limit. Once the limit is exceeded, the response should return HTTP 429 Too Many Requests. Verify the response includes a Retry-After header indicating how many seconds the caller should wait before retrying. Verify requests sent before the limit was reached processed correctly.

✅ Duplicate resource creation returns HTTP 409 with a conflict explanation‍

Send two identical POST requests that would violate a unique constraint such as a duplicate email address or order reference. The second request should return HTTP 409. Verify the error body explains the conflict and identifies which field or constraint was violated.

6. Test Cases for API Idempotency and Concurrency

Modern API consumers retry automatically when they encounter network failures or timeouts. These cases verify the API handles repeated and simultaneous calls without producing duplicate results or inconsistent state.

✅ Repeated POST with the same idempotency key creates exactly one resource

‍Send the same POST request three times using an identical idempotency key in the request header. Query the database after all three requests complete and confirm exactly one resource was created, not three. Verify all three responses returned identical bodies and the same HTTP 201 status code. This test case catches the failure mode where retries create duplicate records or charges.

✅ Repeated DELETE of the same resource is handled gracefully

‍Send a DELETE request for an existing resource and confirm it returns HTTP 204. Send the same DELETE request a second time to the same resource ID. The response should return either HTTP 204 or HTTP 404 consistently based on the contract, never an unexpected error. Idempotent delete behaviour prevents retry storms from causing errors in consumers that retry on failure.

✅ Concurrent updates to the same record produce a deterministic outcome‍

Send two PUT requests to the same resource simultaneously with conflicting field changes. After both requests complete, query the database and verify the final state matches either the last-write-wins contract or the optimistic locking behaviour specified in the API documentation. Verify neither request produced a partially applied update.

✅ Concurrent purchases of the last inventory unit result in exactly one success‍

Set the inventory count for a product to one unit. Send simultaneous purchase requests from multiple callers. Verify exactly one request succeeds with HTTP 200 and the remaining requests receive HTTP 409. Query the inventory system to confirm the count reached zero and not a negative number, which would indicate a concurrency defect.

✅ Parallel creation requests with different idempotency keys each create a unique resource‍

Send ten simultaneous POST requests each with a unique idempotency key and unique payload data. After all requests complete, query the database and verify exactly ten resources were created with no duplicates, no missing records, and no field values from one record appearing in another. This case confirms the API handles parallel creation at volume without collisions or data corruption.

7. Test Cases for API Security Testing

APIs handle sensitive data and are a common target for exploitation. These cases verify that security controls are in place and correctly enforced across every endpoint.

✅ SQL injection payloads in query parameters are rejected safely‍

Send GET requests where query parameters contain SQL injection strings such as a single quote followed by OR 1 equals 1. The response should return HTTP 400 with a validation error or process the string as a literal value without executing it as SQL. Verify the database was not queried with the injected string. A HTTP 500 response or unexpected data in the response body indicates a vulnerability.

✅ Cross-site scripting payloads in text fields are sanitised before storage‍

Send POST requests where text fields contain XSS payloads such as a script tag with an alert function. Verify the response does not echo the script back in the response body. Retrieve the stored resource via GET and verify the script tag was either rejected, escaped, or stripped before storage.

✅ All API communication requires HTTPS and plain HTTP requests are rejected‍

Attempt to send requests to every endpoint using HTTP rather than HTTPS. Each request should either receive an immediate rejection or a redirect to the HTTPS equivalent. Verify no endpoint processes a request sent over plain HTTP, which would transmit credentials and payloads in clear text.

✅ Sensitive data does not appear in response bodies or error messages‍

Review every response body across functional, negative, and error test cases for passwords, API keys, secret tokens, payment card numbers, or any other sensitive data category. None of these should appear in any response under any circumstances including error messages and debug output.

✅ CORS headers restrict cross-origin requests to authorised domains only‍

Send requests to the API with an Origin header set to an unauthorised domain. Verify the Access-Control-Allow-Origin response header does not echo back the unauthorised origin and does not contain a wildcard. Send the same request with an authorised domain and verify the correct Access-Control-Allow-Origin value is returned.

✅ Brute force protection limits repeated authentication attempts‍

Send repeated requests to the authentication endpoint with incorrect credentials. After a defined number of failed attempts, verify the API either locks the account temporarily, returns HTTP 429, or requires an additional verification step. Verify the number of permitted attempts matches the documented security policy.

8. Test Cases for API Workflow and Chained Testing

Real API consumers rarely call a single endpoint in isolation. They sequence calls across a journey. Workflow test cases string several requests together to verify end-to-end behaviour and catch defects that single-endpoint tests cannot reach.

✅ Authentication token obtained in step one is used successfully across subsequent steps‍

Send a login request and capture the returned access token. Use that token in the Authorization header for all subsequent requests in the workflow. Verify the token is accepted at each step without requiring re-authentication. This confirms the token is correctly issued and consistently accepted across the API surface.

✅ Resource created in step one is retrievable and modifiable in subsequent steps‍

Send a POST request to create a resource and capture the returned resource ID. Use that ID to send a GET request and verify the resource is retrievable with the correct field values. Then send a PUT request using the same ID and verify the update is applied. This end-to-end sequence confirms the create, read, and update operations are correctly linked through the resource identifier.

✅ Workflow correctly enforces state transitions and rejects invalid ones‍

Walk a resource through its valid state transitions in sequence, for example draft to submitted to approved. At each state, attempt to apply an invalid transition such as moving from approved back to draft. Verify the invalid transitions return HTTP 409 with a clear explanation. This confirms state machine logic is enforced throughout the workflow, not just at the point of creation.

✅ Cancelling a workflow mid-sequence rolls back all changes correctly‍

Begin a multi-step workflow such as creating a quote, binding it to a policy, and initiating payment. After the second step, send a cancellation request. Verify the response confirms cancellation and query the database to confirm all records created in the preceding steps are correctly rolled back or marked as cancelled. This case reveals partial state defects where some records are cleaned up and others are not.

✅ Chained workflow handles downstream service failure gracefully‍

During a multi-step workflow, simulate a failure in a downstream dependency such as a payment gateway or notification service by configuring the test environment to return an error from that service. Verify the API returns a meaningful error to the caller, does not leave the workflow in a partially completed state, and correctly cleans up any records created before the failure occurred.

9. Test Cases for API Data Integrity and Downstream Validation

A successful API response is necessary but not sufficient. Test cases that complete without validating downstream effects miss a major class of defects. These cases verify the full chain, not just the API response.

✅ POST request persists the resource to the database with all correct field values‍

Send a POST request to create a resource and capture the returned resource ID. Query the database directly using that ID and verify every field matches the values submitted in the request. This case confirms the API is not returning a fabricated success response while silently failing to write to the database.

✅ Write operation publishes the correct event to the message bus‍

Send a POST request to create a resource and immediately query the message bus or event stream for the expected event. Verify the event was published with the correct event type, the correct resource ID, and the correct field values. Missing or malformed events break every downstream service that depends on them.

✅ Write operation creates the correct audit log entry‍

Send a POST, PUT, or DELETE request and query the audit log table directly after the request completes. Verify an audit entry was created with the correct action type, the correct resource ID, the correct timestamp, and the correct user attribution. Missing audit entries are a compliance defect in regulated industries.

✅ DELETE operation removes the resource from all relevant tables and systems

‍Send a DELETE request for a resource that has related records in other tables such as an order with associated line items, payments, and audit logs. After the request completes, query every related table and verify all related records were handled according to the documented deletion policy, whether that is hard deletion, soft deletion, or cascading. A response of HTTP 204 with orphaned records remaining in related tables is a data integrity defect.

‍

How to Write API Test Cases That Actually Catch Defects

Writing test cases that hold up over time requires discipline at the design stage. These practices reflect what works in production API testing programmes.

Read the Contract Before Writing a Single Case

An OpenAPI or Swagger specification is the authoritative source of truth for what the API promises. Read it in full before authoring test cases. Every endpoint, every parameter, every status code, and every response schema in the specification is a test case waiting to be written.

Extend the Contract with Business Rules

Contracts describe technical behaviour. They rarely capture the business rules that constrain it. A field accepting values up to one million may be restricted to one thousand for a specific customer tier by a business rule that does not appear in the specification. Domain experts, product documentation, and support data all surface these rules.

Cover Failure Conditions as Thoroughly as Success Conditions

A suite where the majority of cases test successful operations produces high pass rates and limited confidence. At least half the cases in a healthy suite should exercise failure conditions: missing fields, invalid values, boundary violations, authentication failures, and error response quality.

Always Assert on the Response Body

A status code check passes too easily. Asserting on specific field values, types, and schema compliance is what proves the API actually did what it claimed rather than returning a placeholder response.

Validate Postconditions, Not Just Responses

A successful HTTP 201 confirms the API accepted the request. It does not confirm the resource was persisted correctly. Every test case for a write operation should verify the downstream state: database records, event publications, audit log entries, and inventory changes.

Keep Test Data Outside the Test Case

Tokens, IDs, environment URLs, and base paths hard-coded into test cases stop the suite from running in other environments. Store all configuration as parameterised variables. Test cases should reference variables, not literal values.

Common Mistakes in API Test Case Design

Several patterns produce suites with high pass rates and low protection.

1. Over-reliance on Happy Paths

‍A suite where 90% of cases test successful operations catches fewer defects per case than a balanced suite. Failure conditions, boundary values, and error response quality all require explicit coverage.

2. Hard-coded environment values

‍Tokens, IDs, and URLs baked into test cases prevent the suite from running in another environment without manual updates. Configuration belongs in variables.

3. No Body Assertion

‍A status code check alone confirms the API responded. It does not confirm the response was correct. Assert on field values, types, and schema compliance in every case.

4. Missing Postcondition Checks‍

A pass without database verification is half a test. Write operations need downstream state validation to prove the full chain worked.

5. No Version Coverage

‍APIs have at least two active versions at any given time. Test cases for older versions are not optional until those versions are formally retired.

6. Uniform Timeouts

‍Tight latency assertions belong on critical endpoints. Applying the same timeout to every endpoint hides regressions on high-priority paths or generates noise on low-priority ones.

The AI-Native Shift in API Test Case Creation

Two limits broke the original economics of API test case design: authoring took too long and maintenance consumed the savings that automation was supposed to deliver.

AI-native test platforms address both by changing where the effort goes. Rather than engineers spending weeks translating specifications into test scripts, generation tools ingest OpenAPI specifications, Gherkin scenarios, and BRDs to produce executable test cases automatically. The practitioner's role shifts from authoring to reviewing and extending with business rules and edge cases that contracts cannot capture on their own.

Maintenance overhead shrinks through self-healing. Tests that combine UI, API, and database steps were historically the most fragile assets a team could own. A single locator change broke the entire chain. Self-healing capabilities keep these assets stable through application change so the test value compounds rather than depreciates with every release.

Natural language authoring removes the engineering bottleneck from test creation entirely. A practitioner specifies the journey in plain English and the platform translates intent into executable steps. The asset is reviewable by product managers, support teams, and domain experts, not just by engineers fluent in a particular automation framework.

When failures occur, AI Root Cause Analysis identifies which step in a chained journey actually broke rather than surfacing a single red result that could mean anything. Correlating logs, network requests, screenshots, and UI state together cuts defect triage time significantly.

How Virtuoso QA Handles API Test Cases

Virtuoso QA treats API testing as a first-class part of every journey rather than a bolt-on capability.

• Unified journeys combine UI actions, API calls, and SQL validations in a single test asset so postcondition verification is built in rather than added as an afterthought
  ‍
• GENerator drafts test cases from specifications, requirements, application screens, or legacy suites, accelerating coverage by weeks rather than months
  ‍
• Self-healing at approximately 95% accuracy keeps API and UI assets stable through refactors and AI-driven code changes without manual locator updates
  ‍
• CI/CD integration with Jenkins, Azure DevOps, GitHub Actions, GitLab, and CircleCI runs the right cases on the right triggers, driven by change rather than schedule
  ‍
• Composable libraries allow API test cases to be reused across products, environments, and partner deployments without rebuilding from scratch
  ‍

Interesting Reads

• ‍Functional Testing - Definition, Lifecycle, and Types‍
  ‍
• Unified Test Automation: One Platform for UI and API Testing‍
  ‍
• Functional Test with Fake API Data‍
  ‍
• API Regression Testing: A Complete Guide for QA Teams‍
  ‍
• API Functional Testing - Definition, Importance, and Role of AI
  ‍