API Testing Checklist.

For every endpoint in the OpenAPI spec, send a minimal valid request and assert the status code is not 404 or 405. Catch documentation drift early — if the spec says GET /users exists, the server must agree.

Send a DELETE to a read-only resource (e.g. DELETE /users if only GET is supported). Expect exactly HTTP 405 and an Allow response header listing the supported methods (e.g. 'Allow: GET, HEAD').

A HEAD request to a GET endpoint must return identical headers to a GET but with no body. An OPTIONS request to a cross-origin endpoint must return the CORS headers your client expects.

Request GET /users and GET /users/. Both should behave identically (both 200, or 200 + 301 redirect to the canonical form). Inconsistency causes client-side bugs when frameworks normalise URLs differently.

Send a POST/PUT with a required field removed. Expect HTTP 400 and a JSON error body that names the missing field (e.g. {"error": "'email' is required"}). A generic 'Bad Request' string is not sufficient.

POST to a JSON-only endpoint with Content-Type: application/x-www-form-urlencoded. The API should return 415, not silently parse partial data or return 500.

Send a numeric field as a string (e.g. {"age": "twenty-five"}) and a boolean as "true" (string). The API should return 400 with a type-mismatch message, not silently coerce or return NaN.

Send a POST with an extra field not in the schema (e.g. {"role": "admin"}). The API must either strip it silently or return 400. If it stores and returns the extra field, a mass-assignment vulnerability exists.

Try GET /users/1' OR '1'='1 and GET /users/../admin. Expect 400 or 404, never a 200 with unexpected data. Check the server does not log the raw unescaped string in a way that could cause log injection.

Send a request body larger than the server's configured limit (try 10 MB for APIs with a 1 MB limit). Expect 413, not a timeout or an OOM-induced 500.

Validate every 2xx response body against the schema defined in the OpenAPI spec using a JSON Schema validator. Required fields must always be present; optional fields must conform to their declared types when present.

Inspect the Content-Type response header. APIs returning JSON without declaring it cause silent parsing failures in typed clients and strict HTTP parsers.

GET /users when no users exist should return {"users": []} not {"users": null}. An optional field like 'avatar' should be absent from the JSON entirely when not set, not present with value null — unless the schema explicitly allows null.

Assert that date fields like 'createdAt' and 'updatedAt' match the pattern /^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?Z$/. Mixed formats (Unix timestamps, US-formatted dates) in the same API are a frequent source of client-side bugs.

Send the same GET request 3 times in succession and compare response bodies. Differences are acceptable only if the endpoint is explicitly documented as non-deterministic (e.g. random sampling). Status codes must be identical.

Send a request to any protected endpoint with the Authorization header omitted entirely. Expect HTTP 401 Unauthorized — not 200 with an empty payload, not 403, and not a redirect to a login page (for APIs).

Forge or generate a JWT with an exp claim in the past. Send it to a protected endpoint. Expect 401 and ideally a WWW-Authenticate: Bearer error=invalid_token, error_description='Token expired' header.

Take a valid JWT, decode the payload, change a claim (e.g. sub or role), re-encode (without re-signing), and send it. The server must reject it with 401 — it must not read the unverified payload.

Use a token granted only the 'read:profile' scope to call a 'write:posts' endpoint. Expect 403, confirming the token scope is checked, not just the token's validity.

If the API implements refresh token rotation: call /token/refresh with a valid refresh token (obtaining a new pair), then call /token/refresh again with the same old refresh token. The second call must return 401 and ideally invalidate the new tokens too (token family invalidation).

Create two accounts: User A and User B. User B creates a resource. Authenticate as User A and attempt GET, PUT, PATCH, and DELETE on User B's resource. Each must return 403 (or 404 if the API prefers to hide existence).

Authenticate as a non-admin user and call endpoints documented as admin-only (e.g. GET /admin/users, DELETE /users/:id). Expect 403, confirming role checks are enforced server-side — not just hidden from the UI.

As User A, note the resource ID returned by the API (e.g. /orders/1042). Try incrementing or decrementing it: GET /orders/1041. If this returns User B's order, an Insecure Direct Object Reference vulnerability exists.

If the API supports token scopes or roles, issue a read-only credential and attempt POST/PUT/PATCH/DELETE. Every write endpoint must return 403.

Call GET /users with no query parameters. The response should include a bounded result set (e.g. 20 items) plus pagination metadata (total, next cursor, or next page link). It must not return all records unbounded.

Paginate through a collection to the final page. The response should contain only the remaining items (possibly fewer than the page size), and the 'next' link or cursor should be absent or null — not an empty page.

Request GET /users?limit=-1, GET /users?limit=0, and GET /users?limit=100000. Expect 400 for invalid values and a capped result (e.g. max 100 items) for the oversized request — not a full table scan.

Request GET /users?status=active. Every record in the response body must have status === 'active'. Verify with at least one filter that has a known count of matching records.

Request GET /users?nonexistent_field=value. Expect 400 with a message indicating the field is unrecognised — not 200 with an empty array, which would mask typos in client code.

Request GET /users?sort_by=created_at&order=asc. Assert that consecutive records have non-decreasing created_at values. Then flip to desc and assert non-increasing. Include a test with equal values (same timestamp) to verify stable sort behaviour.

Request GET /users?sort_by=1;DROP+TABLE+users--. Expect 400, not a 500 or — worse — a successful query. The API must validate sort_by against an allowlist of permitted column names.

Trigger validation errors, authentication failures, and not-found cases. Every error response must return Content-Type: application/json with a structured body — not an HTML error page from the framework or a raw string like 'Unauthorized'.

Check all error paths — invalid input, auth failure, not-found. The status code must reflect the error semantics. Returning {"success": false, "error": "Not found"} with HTTP 200 breaks HTTP clients that branch on status code.

Trigger a server error (e.g. by sending a malformed request that causes an unhandled exception). The 500 response body must not contain a stack trace, file system path, or database query. These are valid in development but must be suppressed in production.

Compare error bodies from validation errors, auth errors, and server errors. The top-level keys should be identical across all error types. Inconsistent error shapes force clients to write defensive parsing for every endpoint.

Send N+1 requests in a short window (where N is the documented limit). Expect HTTP 429 with a Retry-After header on the N+1th request. Without rate limiting, credential-stuffing attacks and enumeration are trivial.

Send an OPTIONS preflight from a disallowed origin. The Access-Control-Allow-Origin header must not return * for credentialed requests. It should either reflect only the allowed origin or be absent.

Inspect GET /users/:id and GET /me responses. Fields like 'password', 'password_hash', 'secret', 'api_key', and 'internal_id' must not appear. Check both the successful and error paths.

Send a plain HTTP request to the API base URL. Expect a 301 or 308 redirect to the HTTPS equivalent. An API serving on HTTP exposes tokens in transit.

Send POST /auth/login with a nonexistent email, then with a valid email and wrong password. Both must return the same 401 response body. Differentiating them allows user enumeration attacks.

Run the spec through a validator (e.g. openapi-cli validate, Spectral) and assert zero errors. Warnings about missing descriptions or deprecated fields are acceptable; structural errors are not.

For each endpoint, trigger all documented status codes (200, 201, 400, 401, 403, 404, 429, 500) and verify the spec lists each one with a correct schema. Undocumented status codes break generated client SDKs.

Extract examples from the OpenAPI spec and validate each against the corresponding request/response schema. Stale or hand-crafted examples that violate the schema mislead API consumers.

Use a tool like Schemathesis or Dredd to replay the OpenAPI spec against the running API and assert all endpoints conform. A spec that drifts from reality is worse than no spec.