API pagination, filtering, and sorting bugs

Every list endpoint does the same three things: it pages, it filters, and it sorts. They look trivial, which is exactly why they ship broken — nobody budgets test time for "the list endpoint." But these three interact in nasty ways, and the bugs are subtle enough to pass a casual look and serious enough to leak data or drop records. This is the deep-dive companion to the 12 API bugs I check first; here's the full pass for list endpoints specifically.

Pagination: the records have to add up

The one invariant that matters: page through the entire list and you should see every record exactly once. Almost every pagination bug is a violation of that. The checks:

• Repeats across pages. Grab page 1 and page 2, compare IDs. Any overlap means records are being shown twice — usually because the underlying order isn't stable (see sorting, below).
• Skipped records. The gap version of the same bug: a record that's on neither page. Hardest to spot, most damaging — data that simply can't be reached through the UI.
• The boundaries. Page 0 vs page 1 (which is the first page?), the very last page (does next 404 or return empty?), a page beyond the end (clean empty list, or error?), and pageSize=0 or a huge pageSize (is it capped, and does it tell you?).
• The total count. Does the reported total match the number you can actually page through? A total: 100 that only yields 95 reachable records is a real, reportable bug.

Filtering: it has to match, and it has to fail closed

Two failure modes, one dangerous:

• Does the filter actually filter? status=archived should return only archived items. Check the result really matches — and check combinations (status=archived&owner=me) compose with AND, not OR.
• The fail-open leak. This is the one that matters. Send a misspelled or unsupported filter — staus=archived, or owner=me on an endpoint that doesn't support it. A safe API rejects it (400) or returns nothing. A dangerous one silently ignores the unknown parameter and returns everything — which, on an owner-scoped endpoint, means returning every user's data. Always test the unknown-filter case; "ignored silently" is both a correctness and a data-exposure bug.
• Empty and weird values. filter= (empty), special characters, a date filter with a malformed date. Reject or handle — never 500.

Sorting: stable, and actually sorted

• Is it sorted at all, in both directions? sort=name&order=asc and desc. Check the ends of the list, not just that it "looks sorted."
• Stability on ties — the sneaky one. Sort by a field with duplicate values (ten rows sharing a createdDate) and fetch the same page twice. If the order of the tied rows changes between identical requests, the sort is unstable — and this is what causes the pagination repeats-and-skips above, because page boundaries land in different places each request. It looks like flaky tests; it's a real defect in the endpoint.
• Sorting by something you can't see / shouldn't sort by. sort=passwordHash, sort=nonexistentField — reject cleanly, don't 500 or ignore-and-leak.

They interact — test them together

The bugs hide in the combination. An unstable sort only causes visible pagination corruption when you page through it. A filter leak is worse when it interacts with pagination (you page through everyone's data). So the highest-value test is the realistic one: filter + sort + page through to the end, and confirm you got exactly the records you should, once each, in order.

Where this fits

These are concrete enough to automate once you've found them by hand. The API testing checklist has the structured version, and the tools directory covers Postman, Bruno, REST Assured, and Karate for turning the keepers into a suite. For the wider list of API defect classes, start with the 12 API bugs.

List-endpoint pass

• Page through everything: no repeats, no skips, every record once
• Boundaries: first page, last page, beyond-the-end, pageSize 0 and huge
• Reported total matches the reachable record count
• Filters match exactly and compose with AND
• Unknown/misspelled filter is rejected — never "return everything"
• Sort works both directions and is stable on tied values across identical requests
• Sort/filter on disallowed or nonexistent fields fails cleanly, not with a 500 or a leak
• The realistic combo: filter + sort + full page-through returns the right set, once each