A REST API testing checklist you can actually finish

Most REST API testing checklists are aspirational: fifty items long, and nobody finishes them before the sprint ends. This is the REST API testing checklist I actually run in Postman, organized as passes in risk order — so if time runs out, you have covered the dangerous things first instead of the endpoints in alphabetical order.

Pass 1: the smoke pass

For every endpoint, hit the happy path and confirm three things: the status code is correct (a real 201 or 204, not a lazy 200 for everything), the response body is valid JSON, and it comes back in a reasonable time. Then hit each endpoint with no auth token, an expired token, and a valid token belonging to a different user. Broken authorization is the highest-risk bug an API can ship, and this check takes minutes. If I only get one pass on a build, it is this one.

Pass 2: contract and schema

Compare responses to whatever contract exists — an OpenAPI spec, the docs, or a saved known-good example. Field names, types, nullability, date formats. In Postman I write a schema assertion once per endpoint so this pass runs itself from then on:

pm.test("matches schema", () => {
  pm.response.to.have.jsonSchema(userSchema);
});

Contract bugs are cheap to catch here and expensive later, when a mobile app crashes because a field quietly changed from a number to a string.

Pass 3: behavior

This is pagination, filtering, and idempotency. Pagination: request page one and page two and check for overlapping or missing records, then request a page past the end and see what comes back. Filtering: combine two filters and confirm results match both, then send an invalid filter value and expect a clean 400, not a 500. Idempotency: send the same POST twice — did you just create a duplicate? Retry a PUT and confirm the resource is stable. When the response alone cannot prove correctness, I check the database directly with SQL; an API that returns 200 while writing the wrong row passes every surface-level test.

Pass 4: errors and edges

Force failures on purpose and read the error bodies. A good error response has a consistent shape across endpoints, a machine-readable code, a human-readable message, and no stack traces or SQL fragments leaking out. Send malformed JSON, missing required fields, wrong types, and absurdly long strings. Confirm that a 404 for a missing resource is distinguishable from a 403 for someone else's resource — clients need to react differently to each.

Pass 5: performance smoke and versioning

This is not load testing. Run the collection through the Postman runner for a few dozen iterations and watch for endpoints whose response times degrade or spike — that is usually an N+1 query or a missing index announcing itself early. Then versioning: confirm the API version is explicit in the path or a header, and that clients pinned to the previous version still get answers after a deploy.

The REST API testing checklist

1. Happy path: correct status codes, valid JSON, sane response time
2. Auth: no token, expired token, another user's token
3. Schema matches the contract — automate the assertion
4. Pagination: overlap, gaps, past-the-end page
5. Filtering: combined filters, invalid values fail cleanly
6. Idempotency: repeated POST and PUT behavior
7. Error bodies: consistent shape, nothing leaking
8. Performance smoke via the collection runner
9. Versioning: previous version still answers