Pagination (cursor and offset)
Pagination splits a large result set across multiple API responses. Offset-based pagination uses numeric skip-and-limit parameters to address pages by position; cursor-based pagination returns an opaque token that points at the next page. Cursors stay consistent while underlying data changes, whereas offsets can skip or duplicate records — which is why most modern APIs prefer cursors for large or fast-changing collections.
An agent asked to process 'all customers' must discover the pagination mechanism from documentation alone: the parameter names, the page-size limits, where the next cursor appears in the response, and how the final page is signaled — an empty result, a `has_more` flag, or a missing cursor. Get any of these wrong and the agent either loops forever or silently truncates the data set.
Cursor opacity cuts both ways for agents. It prevents the skipped-record bugs of offsets, but it means the agent cannot construct page URLs itself — it must faithfully thread the token from each response into the next request, exactly as documented. Docs that show a complete paginated loop, request and response together, give a model a pattern it can reproduce reliably.
Pagination also compounds with rate limits: enumerating a large collection is a sustained burst of requests, so the two documented together let an agent plan a traversal that finishes.
Discry records whether pagination is documented as one of the execution-documentation facts on an API's profile ('Pagination documented') — a check-level fact about whether the public docs explain the mechanism an agent must follow, not a runtime test of the endpoints themselves.
What does an AI agent make of your API?
Find out in about a minute — no signup.
Discry your API — free