The 12 API bugs I check for first
A high-value checklist: the twelve API bugs that surface most often, from wrong status codes to idempotency failures.
Series
The recurring API defects worth finding by hand — and the ones worth automating after. APIs break in the same handful of ways on every project. This series walks the defect classes a tester should know cold: the everyday bugs, the list-endpoint traps, and where contracts and query language actually change how you test.
// overview
Most API testing advice jumps straight to frameworks and assertions. This series goes the other way: it starts with the bugs. Learn the defect classes that recur on every API — wrong status codes, missing validation, broken pagination, fail-open filters, unstable sorts, and the auth gaps two accounts will expose — and you'll know what to look for before you write a line of automation.
The arc runs from the broad first pass to the specific traps: the everyday checklist, then the list-endpoint failures that hide behind “it returned 200”, and finally the structural questions — how REST and GraphQL change what you test, and where contract testing genuinely helps versus where the marketing oversells it.
By the end you'll have a hand-run pass that catches more real defects than a green suite, and a clear sense of which of those checks are worth automating.
// reading order
A high-value checklist: the twelve API bugs that surface most often, from wrong status codes to idempotency failures.
Skip the full registry — learn the dozen status codes that carry real meaning, what each promises, and how to spot when the code and the body disagree.
The specific bugs that hide in paginated, filtered, and sorted endpoints — off-by-one pages, unstable sorts, and filter leaks.
The API ships weeks before the screen. Test it directly from the contract — the whole bad-input, auth, and edge class is open at the API and invisible once the UI hides it.
Most 'REST vs GraphQL' content is about API design. The testing perspective is different — query construction, schema-aware tooling, the N+1-shaped test bug, and why GraphQL flips the test pyramid.
Contract testing is two things wearing one name: a model and a tool. The model is genuinely useful; the marketing for the tool oversells where it fits. Here's the model, separated from any vendor's pitch.