API Testing Checklist and Test Case Template for Web and Mobile Apps

Overview

API testing is more than confirming that a successful request returns a successful response. A dependable test cycle checks whether the service behaves correctly with valid, invalid, incomplete, duplicated, delayed, and unauthorized input. It also verifies that changes do not break existing clients, mobile applications, background jobs, or third-party integrations.

Start by turning each endpoint or GraphQL operation into a small contract. Record its method or operation name, URL, authentication requirement, inputs, expected response, side effects, and likely failure conditions. This gives testers and developers a shared reference before they select tools or write automated checks.

For REST APIs, test the route, HTTP method, headers, query parameters, path parameters, request body, status code, response headers, and response schema. For GraphQL, test queries, mutations, variables, field selection, validation errors, authorization at both operation and field level, and the structure of the data and errors responses.

Use an API client, contract-testing framework, integration-test suite, or command-line tool that can run the same cases locally and in CI. A formatted request saved with its expected result is useful for exploration, but automated assertions are what make the result repeatable.

Checklist by scenario

1. Authentication and authorization

• Confirm that an unauthenticated request is rejected where authentication is required.
• Test valid, expired, malformed, revoked, and incorrectly scoped credentials.
• Verify that a user can access only the resources and actions permitted by their role or token scope.
• Check tenant, account, or organization boundaries if the application serves multiple customers.
• Confirm that sensitive values are not returned in error messages, logs, or response headers.

Document the expected behavior for each credential failure rather than asserting only that the request fails. Teams comparing API keys, OAuth 2.0, JWTs, or other methods can use the API authentication methods comparison as a planning reference. Never place real production secrets in test collections or source control.

2. Request validation

• Send a valid minimum request and a valid request containing optional fields.
• Omit required fields, use null values, send empty strings, and provide incorrect data types.
• Test boundary values such as zero, negative numbers, maximum lengths, large payloads, and invalid dates.
• Try unexpected fields and confirm whether the API rejects, ignores, or safely handles them according to its contract.
• Check validation for nested objects, arrays, enumerations, and mutually dependent fields.

Assertions should verify both the failure status and the useful shape of the error response. A client should be able to identify which input failed without receiving implementation details.

3. Status codes and response schemas

• Verify the expected success status for create, read, update, delete, and asynchronous operations.
• Check common client, authorization, conflict, not-found, rate-limit, and server-error paths.
• Assert response content types, required fields, field types, nullability, and key formats.
• Confirm that empty collections, empty results, and deleted resources use a documented representation.
• Check that response headers, caching directives, correlation identifiers, and location headers are present when required.

Do not make tests overly dependent on fields that are allowed to change, such as timestamps or generated identifiers. Assert their type, format, and relationship to the request instead.

4. Pagination, filtering, sorting, and search

• Test the first page, a middle page, the final page, and a page beyond the available results.
• Verify page size limits and behavior for zero, negative, missing, or unusually large limits.
• Confirm that cursors or offsets advance without skipping or duplicating records.
• Test filters with one match, no matches, multiple filters, invalid values, and special characters.
• Check whether sorting is stable when two records have equal sort values.

Use a fixture set large enough to expose ordering and boundary problems. Pagination tests should also verify the metadata or continuation token that clients need to request the next result.

5. Rate limits, retries, and idempotency

• Confirm the documented response when a client exceeds a limit.
• Check whether retry guidance is communicated through headers or response fields where appropriate.
• Repeat safe read requests and verify that they do not create side effects.
• Send the same idempotency key twice for a create or payment-like operation and confirm that it does not produce duplicate work.
• Test interrupted requests, client timeouts, and retries after a connection failure.

Idempotency tests should distinguish between a safe repeat of the same request and reuse of a key with different request data. The latter should be rejected or handled according to the service contract.

6. Webhooks and asynchronous work

• Verify webhook signatures, timestamps, event identifiers, and payload schemas.
• Test duplicate delivery, delayed delivery, out-of-order events, and unknown event types.
• Confirm that the receiver acknowledges valid events quickly and handles processing separately when needed.
• Check retry behavior after a temporary failure and ensure permanently invalid events do not loop indefinitely.
• Verify that background jobs expose a reliable status or result for clients to query.

7. GraphQL-specific cases

• Run valid queries with minimal and expanded field selections.
• Test missing variables, wrong variable types, invalid field names, and malformed operations.
• Check authorization on individual fields, not only at the top-level operation.
• Test mutations for validation, duplicate submissions, partial failures, and transactional behavior.
• Check query complexity, depth, batching, and pagination controls where the service uses them.

GraphQL tests should assert both the returned data and the contents of the errors array. A response can contain partial data and errors at the same time, so a test that checks only the HTTP status may miss a functional failure.

What to double-check

Data integrity and side effects

After a write request, query the affected resource and verify the stored result rather than trusting the immediate response alone. Check relationships, totals, status transitions, audit fields, and downstream effects. Repeat the check after a failed request to confirm that the operation did not partially change data when atomic behavior is expected.

Performance and capacity

Measure representative requests with realistic payloads and response sizes. Include slow database queries, large collections, concurrent users, and dependency delays where they reflect production behavior. Define practical thresholds for latency, error rate, and throughput, then connect them to a broader web app performance budget. Capacity assumptions should be recorded alongside the test, since a passing functional test does not prove that the service can handle expected traffic.

Security and privacy

Check authorization boundaries, input handling, sensitive-data exposure, excessive response fields, replay behavior, and abuse controls. Use synthetic data whenever possible. Test that logs and error responses do not reveal tokens, passwords, personal data, database details, or internal stack traces. Security testing should complement, not replace, a formal review appropriate to the application’s risk.

Backward compatibility

Run existing client scenarios against the new build. Pay particular attention to renamed fields, changed defaults, stricter validation, enum changes, pagination behavior, and altered error shapes. For GraphQL, removing or changing a field can affect clients that request it even when the server still returns a successful HTTP response. Preserve old contract tests until dependent clients have migrated.

For debugging, an online JSON formatter and validator can make payload differences easier to inspect, while a JWT decoder and token debugger can help examine non-sensitive test tokens. These tools should not receive production credentials or confidential payloads.

Common mistakes

• Testing only the happy path: Add invalid, unauthorized, empty, duplicate, delayed, and oversized inputs.
• Asserting only status codes: Validate response schemas, business rules, side effects, and error details.
• Using fragile test data: Create isolated fixtures and avoid assumptions about record order or shared state.
• Ignoring dependencies: Test timeouts, unavailable services, malformed dependency responses, and recovery behavior.
• Putting everything in end-to-end tests: Use unit, contract, integration, and focused security tests at the appropriate layer.
• Skipping CI execution: Run a fast smoke set on every change and broader regression suites before release.
• Failing to clean up: Remove created records or use disposable environments so one test cannot contaminate another.
• Treating documentation as proof: Compare the documented contract with observed behavior and resolve differences before release.

When to revisit

Use this checklist before every new endpoint, schema change, integration launch, mobile release, and production deployment. Revisit it after changes to authentication, database structure, hosting, queues, rate limits, API gateways, or third-party dependencies. Run the full regression set when the risk is broad; for a small change, select the affected scenarios and retain evidence of what was not rerun.

Review the checklist at least during each planning cycle and whenever your testing tools, API protocols, deployment workflow, or security expectations change. Keep the test case template with the endpoint contract so it evolves with the service.

Test case: [name]
Endpoint or operation: [method and path / GraphQL operation]
Purpose: [behavior being verified]
Preconditions: [account, fixture, feature flag]
Request: [headers, parameters, body, variables]
Expected result: [status, response schema, side effects]
Negative cases: [invalid, unauthorized, duplicate, timeout]
Environment: [local, staging, CI]
Evidence: [run ID, log, or report]
Result: [pass, fail, blocked]

Start with one representative endpoint, complete the template, automate its highest-value assertions, and then apply the pattern across the service. For deployment planning, pair the API test results with your cloud app rollback runbook and monitoring plan. That combination makes testing actionable: you know what should work, how to detect a regression, and how to recover when a release does not meet the contract.