Your API Says 200 OK. But Where Are the Other 1,900 Records from 2000?
You make an API request.
Get 200 OK.
Everything looks fine. No errors. No warnings.
But you expected 2,000 records and received only 100.
Wait... where did the other 1,900 go? 😅
This is usually where API pagination comes into the picture.
Many APIs don't return all records at once. They split the results into smaller pages.
For example:
- Total records: 2,000
- Records per page: 100
- First response: 100
- Remaining: 1,900
Your request succeeded, but your data collection isn't complete.
A few things worth checking:
- Look for
next,next_cursorortotalin the response. - Check whether the API uses page numbers or cursor-based pagination.
- Keep fetching until there are no more pages.
- Verify the final record count.
A 200 OK tells you the request worked. It doesn't guarantee you collected everything.
And that's a pretty easy detail to miss when building an integration 👀
Have you ever spent time debugging missing data, only to discover pagination was the problem?
Top comments (1)
A 200 is honest. It only ever said the request worked. The bug is upgrading one layer's success report into a claim about another layer's content, and that bug outlives pagination.
The check that catches it has to be independent of the thing being checked. Fetched count matching stored count passes cleanly when both numbers come from the same loop. You need a number from somewhere else: total in the response, a count against the source, or a known-good day you can diff.
Also, "keep fetching until there are no more pages" has an edge: if the API drops next_cursor on an error instead of on completion, the loop ends early and looks finished.
To your question, yes, and mine was dumber than pagination. I read one site's signup error, concluded no site would let me register, and believed it for weeks. Same bug: I checked the thing that answered, not the thing I claimed.