An API checklist to run per endpoint, not per project

Contract and schema, input validation, authentication and object level authorisation, error behaviour, security, performance and asynchronous flows. Every check states why it earns its place, and the ones that should block a release are flagged.

34checks/6groups/9blocking items/FreeCSV download

All 34 checks, grouped by when they apply

Free to use and adapt, no sign-up. Download as CSV or Markdown, or copy it straight into your own tooling.

Last updated 20 August 2026

0 of 34 complete

Ticking is local to your browser and is not saved or sent anywhere.

Contract and response shape

Run these for every endpoint. Structural drift is what silently breaks consumers.

Response validated against a schema, not only field by fieldBlockingField assertions only catch what you thought to check. A schema catches a type changing from number to string.
Response matches the documented OpenAPI or Swagger specificationDrift between implementation and documentation is one of the most common real defects in an API estate.
Correct status code for success, including 201 with a Location header on creationClients branch on status. A 200 where 201 is documented breaks consumers that check for it.
Content-Type correct on both request and responseA mismatch here causes real client failures that are invisible when testing with a permissive tool.
Null, empty and missing optional fields handled distinctly and consistentlyAbsent, null and empty string mean different things. Consumers need the API to be consistent about which it returns.
Date, decimal and currency formats consistent across every endpointMixed date formats or float-based money across endpoints force every consumer to write special cases.

Input validation

Each required field rejected when missing, with the field named in the errorA generic "invalid request" forces the client developer to guess which field failed.
Wrong types rejected: string where number expected, array where object expectedWeak type handling is where 500s come from, and a 500 for bad input is always a defect.
Boundary values tested: minimum, maximum, just outside, zero, negativeBoundaries are where comparison logic lives, which is where off-by-one errors live.
Oversized payloads and very long strings rejected cleanlyUnbounded input is both a stability risk and a denial-of-service vector.
Unicode, emoji and right-to-left text round-trip without corruptionEncoding defects usually surface as silently mangled data rather than an error.
Unexpected extra fields either ignored or rejected, consistently and by designSilently accepting unknown fields hides client-side typos that then never take effect.

Authentication and authorisation

Request without credentials returns 401, not 403 or 200Blocking401 means unauthenticated and 403 means not permitted. Confusing them misleads clients into not refreshing a token.
Expired and tampered tokens rejected, including a token signed with the wrong keyBlockingA signature that is not verified is an authentication bypass rather than a validation gap.
A JWT with the algorithm set to none is rejectedBlockingAccepting it is a classic and complete authentication bypass.
Object level authorisation tested: authenticate as user A, request user B resourceBlockingBroken object level authorisation is the most common serious API vulnerability and one of the cheapest to test for.
Every role tested against every protected endpoint, including nested and bulk routesPermission gaps hide in the endpoints nobody demos: exports, reports and bulk operations.
Token expiry actually enforced, and refresh and revocation behave as documentedAn expiry claim that is present but unenforced provides no protection at all.

Errors and edge behaviour

Error responses follow one consistent structure across the whole APIInconsistent error shapes force every consumer to special-case each endpoint.
Errors carry a stable machine-readable code, not only human textClients that branch on English message text break the moment the copy is reworded.
No stack traces, SQL fragments, internal hostnames or library versions in any errorBlockingError output is a reconnaissance source, and this is the cheapest place to leak it.
Idempotency verified on create and payment endpoints, including retried requestsBlockingNetworks retry. Without idempotency, a timeout on a charge becomes a duplicate charge.
Concurrent updates to the same resource resolve predictablyLast-write-wins may be acceptable, but it has to be a decision rather than an accident.
Pagination boundaries tested: page beyond last, page size at and above maximum, unstable sortNon-deterministic ordering silently duplicates and skips records across pages.

Security and transport

HTTPS enforced, with plain HTTP redirected or refusedBlockingA single plaintext request is enough to expose a token.
Injection payloads tested in every parameter, including headers and query stringsValidation is often applied to the body and forgotten on headers and path parameters.
Rate limiting present on authentication and expensive endpoints, returning 429 with Retry-AfterWithout it, credential stuffing and accidental client loops both take the service down.
Sensitive data absent from URLs, logs and analyticsBlockingTokens in query strings end up in server logs, browser history and referrer headers.
CORS configuration verified against the intended origins, not left permissiveA wildcard origin on an authenticated API exposes it to any site the user visits.

Performance and integration

Response time measured at p95 under expected concurrency, not as an averageAn average hides the tail, and the tail is what users actually experience.
List endpoints checked for N plus 1 query behaviour against realistic data volumeAn endpoint that is fast against twelve seed records can be unusable against ten thousand.
Third-party dependency failure simulated: timeout, 500, malformed response, slow responseYou cannot ask a provider to fail on demand, so stub it and verify retry, backoff and fallback.
Asynchronous flows verified end to end, including webhook duplicates and out-of-order deliveryWebhooks are retried and can arrive twice or out of sequence, and both cases occur in production.
Contract tests run in both consumer and provider pipelinesA breaking change should fail the provider build, not be discovered later in a shared environment.

How To Use This

Work it per endpoint, not once per release

API coverage gaps form endpoint by endpoint. One gets the full treatment, the next gets a status code check and ships.

Authorisation on every endpoint

The object level authorisation check is the highest-value item here. Run it on every route that takes an identifier, including exports.

Automate the repeatable parts

Schema validation, status codes and auth negatives belong in the pipeline. Reserve manual effort for the scenario work.

Stub what you cannot break

A provider will not return a 500 on demand. Stubbing is the only way to verify your retry and fallback behaviour.

Test the errors as a contract

Error shape, codes and leakage are part of the API contract. Consumers depend on them as much as the success path.

Why These Checks

The four checks that catch the most serious defects

Object level authorisation is first for a reason. Authenticate as one user, capture a resource identifier, then request it as another and confirm you are refused. It takes a minute per endpoint, it is rarely done systematically, and it is the top entry on the OWASP API Security list. With sequential identifiers it turns from a single-record leak into mass data exposure.

Idempotency is second. Networks retry, clients double-submit, and gateways time out after the work has already been done. Without an idempotency key or equivalent, a retried charge becomes a duplicate charge, which is the single worst defect class in any payment integration.

Schema validation is third, because it is the only check that catches structural drift. Field-by-field assertions verify what you thought to check; a schema catches a field silently changing type, becoming optional, or disappearing, which is exactly what breaks downstream consumers without breaking your tests.

Error leakage is fourth and the easiest to fix. Stack traces, SQL fragments and internal hostnames in an error response are free reconnaissance, and they usually appear because verbose error handling added during development was never turned off for the deployed environment.

Suggest an improvement

Need API coverage built?

QAble builds API and contract test suites that run in your pipeline, including the authorisation and idempotency checks most teams skip.

API testing services

More templates and checklists

View all

Sources

RFC 9110: HTTP Semantics authoritative definition of methods, status codes and conditional requests.
OWASP ASVS verification requirements for authentication, session and access control.
OWASP Top 10 the risk categories these security cases map to.