A first API testing checklist

Before you send anything

• Read the contract first. List every endpoint, method and expected status before touching the API — your checklist comes from the contract, not from clicking around.
• Note the authentication scheme and where the token goes (header, query, body). Half of first-day failures are auth placement, not auth value.
• Decide what "correct" means for one request: status code, content type, and one or two field values you will actually assert on.

Happy paths

• Call each endpoint once with valid input and confirm the documented success status.
• Check the response body shape, not just the status: a 200 with a different JSON structure than documented is still a bug.
• Confirm required fields are present, and spot-check one value against known data.
• Check the content-type header. JSON returned as text/html breaks parsers silently.

Error and edge cases

• Send a required field as empty or missing. Expect a clear 400-style error, not a 500.
• Send a wrong type (a string where a number is expected) and read the error message: would a real integrator understand what to fix?
• Request a resource that does not exist and confirm the documented 404 shape.
• Send a request with an expired, malformed or missing token and confirm you get 401 or 403 — and that no partial data leaks with it.
• Try a very long string, a large number, and an empty list wherever the contract allows them.
• Call the same endpoint twice in a row. If it creates something, does it create two? That may be correct — but you should know which.
• Send a burst of the same read a few times in quick succession and see whether the API answers 429. If it rate-limits you, the error should say when to retry — a plain failure with no hint is the finding.

The checks people forget

• Test the read-after-write path: create a resource, then fetch it by ID and confirm it is really there.
• Check pagination or list limits if the endpoint returns collections — page one alone proves almost nothing.
• Watch response times on the slowest endpoint. You are not load testing, but a 30-second response on a detail view is worth flagging now.
• Check an error response for stack traces, internal IDs or tokens. Error bodies are public-facing.
• Re-run your happy path after all the abuse above. The API should still work exactly as it did at the start.
• Write down what you tested and what you saw. Twenty checks you cannot re-trace are worth less than five you can.

Turning the list into a habit

The first pass through this checklist is the slow one, because you are reading the contract while you test. The second pass should take a fraction of the time — if you kept notes. That is the whole trick behind repeatable API testing: a table of cases, the expected result for each, and what actually happened. Once your checklist lives in a matrix instead of your memory, you can re-run it after every change and hand it to a colleague.

If you want that matrix ready-made, our API Testing Starter Kit is a $10 entry-level kit built around exactly this: a worked example on a fictional contract, a 20-case editable test matrix, and .http request examples, with the checks above expanded into a full guide. It is self-study material — you bring the API you are authorized to test, the kit brings the structure.