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 (4)
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.
That's a really good point! Especially the idea of validating success independently rather than trusting the same process that produced the result.
The
next_cursoredge case is interesting too. It shows how even a pagination loop can appear to finish successfully while silently missing data.And your signup example is a great reminder that this goes beyond APIs. Sometimes we end up trusting the response instead of verifying the actual outcome 😅
Thanks for sharing this perspective!
Then the harder version: 'verify the actual outcome' only holds if one number comes from outside both systems. If the only source of truth is the same vendor's dashboard, verifying the outcome quietly becomes trusting a different response.
Which means the honest result when nothing outside exists is a loud failure, not a green check. A check that can only ever pass is not a check.
What are you building where the independent number is the hard part? That is the case I have not solved either.
literallly