How Does Pagination Work in APIs? Cursors and Consistency

How Does Pagination Work in APIs?

Scrapeless Agent Browser lets applications interact with paginated web interfaces when collecting results requires browser state or JavaScript execution.

How Does Pagination Work in APIs?

API pagination divides a collection into result windows and gives the client a way to request the next window. The API defines an ordering, a page-size policy, a continuation mechanism, and a completion signal. The client follows that contract until the collection ends or its own permitted collection boundary is reached.

Pagination limits the work and response size associated with each request. It also creates a consistency question: what happens if records change while the client walks through the collection? A complete pagination design explains both how the client advances and which version of the collection the resulting records represent.

TL;DR

  • Pagination requires an ordering and a continuation contract. Page numbers alone do not define consistency.
  • Cursors should be treated as opaque values. Return the token unchanged within the documented request context.
  • An empty page may still have a continuation. Use the API's explicit completion signal.
  • Deduplication cannot recover omitted records. Stable traversal and coverage checks remain necessary.

How Do Page Numbers and Offsets Work?

Page-number pagination identifies a numbered window, while offset pagination identifies how many ordered results to skip before returning a limited set. A page number may be translated into an offset internally, but the mapping and numbering base belong to the API contract. Do not assume the first page is always represented by the same number across services.

These patterns are convenient for interfaces that need direct navigation to a visible page. They can become less predictable when the collection changes during traversal. If an item is inserted before the next offset, the following window can overlap the previous one. If an item is removed, a later window can skip an item.

Ordering must be explicit. The database behavior of LIMIT and OFFSET illustrates why pagination without a unique ordering can produce unpredictable subsets. Ordering by a non-unique creation time alone can still leave ties unresolved. A stable secondary identity can resolve those ties when the data model permits it.

Deep offsets may also require the backend to process rows that are not returned. The actual cost depends on indexes, filters, and implementation. Avoid promising that page-number navigation has constant cost simply because each response contains the same maximum number of records.

How Do Cursor and Keyset Pagination Work?

Cursor pagination returns a continuation value that the client uses to request another window. Keyset pagination is an implementation technique that advances relative to ordered values, such as the last accepted timestamp and identifier. An API can expose an opaque cursor while changing its internal implementation later.

A cursor may encode a position, a snapshot reference, or server-side state. The client should not infer its meaning by decoding it. An opaque value is an interface boundary, and apparent readability does not make its internal fields a supported public contract.

The GraphQL connection pagination pattern describes edges, cursors, and page information. GraphQL as a language does not force every API to adopt that pattern. Clients still need the actual schema and server-specific constraints.

Keyset traversal reduces some movement problems caused by offsets, but it is not automatically a frozen snapshot. If the sort field changes, an item can move across the traversal boundary. If new items are inserted behind the boundary, they may be outside the current walk. State the consistency guarantee the server actually provides.

PatternClient sendsMain design concern
Page numberA numbered window and supported sizePage movement under source changes
OffsetA skip count and limitStable ordering and deep-scan cost
CursorA server-issued continuation valueToken context, lifetime, and consistency
KeysetAn ordered position, often hidden in a cursorSort-key stability and tie-breaking
Next linkThe returned continuation URLDestination validation and credential scope

How Should Next Links and Tokens Be Followed?

Follow a continuation using the API's documented location and request rules. A response can carry a token in its body, a next URL in metadata, or a typed link in an HTTP header. The Web Linking model defines typed links and their relationship semantics, but a client must still understand the API's pagination contract.

Preserve filters, sorting, and other context as required. A token produced for one collection should not be combined with unrelated filters. If a service allows the page size to change during a walk, use that documented permission; otherwise keep the request consistent.

Validate the destination before attaching credentials to a next URL. A returned link is data, not permission to forward a secret to any host it names. Use the allowed service origins and the authentication scope defined by the integration. Avoid constructing URLs by concatenating unescaped cursor text.

Checkpoint the continuation together with its context. A stored token without the collection, filter, ordering, and accepted output boundary is difficult to use correctly later. Some cursors expire, so persistence alone does not guarantee resumability.

How Does a Client Know the Collection Is Complete?

A client knows the collection is complete when the API's documented end signal is satisfied. The signal may be an absent next link, an empty next token, or an explicit page-information flag. A short page or empty array is sufficient only when the contract says it is sufficient.

AIP pagination guidance provides a concrete example: a response can contain fewer results than requested, including no results, while still returning a continuation token. That behavior is not universal, but it disproves the assumption that an empty page always means the walk has ended.

Track termination reasons separately. Source end, client record cap, elapsed-time limit, invalid token, and access failure describe different outcomes. A capped run is a bounded sample or partial collection. It should not be labeled complete merely because the loop stopped normally.

Guard against repeated continuations. If a response returns the same token and no meaningful progress, the client should stop with an unresolved state rather than loop indefinitely. Stable record identifiers can help detect overlap, while a page fingerprint can help identify a repeated response. Neither proves full coverage on its own.

What Does a Correct Traversal Record Preserve?

A traversal record preserves enough context to explain which collection was walked and what output was accepted. In an illustrative activity-export design, store the collection identity, filters, sort order, accepted record keys, and continuation associated with the last durable output boundary.

Commit records before advancing the durable progress marker. Otherwise a process can record progress past records it never saved. Where a transaction cannot cover both output and checkpoint storage, define how the system detects and reconciles that gap.

Deduplicate by the correct identity. A resource identifier may be sufficient for a latest-state export. An event feed may need an event identity. A history export may need both resource and version. Deleting duplicate resource identifiers from a versioned history can remove legitimate changes.

Record the server's consistency promise. Snapshot pagination can provide a stable view if the server implements it. A live cursor walk may represent a moving collection. Consumers should know whether the export is a snapshot, a bounded traversal, or an ongoing change stream.

How Does API Pagination Relate to Website Pagination?

Website pagination adds an interaction layer above the data sequence. A next button can request an API cursor, replace the page, append cards, or update only part of the DOM. The visible page label does not reveal the entire continuation contract.

Scrapeless Agent Browser is relevant when the workflow needs those browser interactions. Its cloud browser capabilities support navigating dynamic pages; your collector still owns identity, stopping rules, and completeness reporting.

The web scraping pagination patterns show common interface shapes. Use an authorized documented API directly when it fits the task. A request visible in browser developer tools does not automatically establish permission to use it outside the intended interface.

Choose page size from supported limits and actual processing needs. Larger pages can reduce request count but increase response size and checkpoint granularity. Review Scrapeless pricing when browser collection is involved, and assess the source API's independent quotas and access policy.

Conclusion

A reliable API pagination client follows the continuation contract, preserves stable ordering context, and records why traversal ended. Before calling an export complete, establish which collection version it represents and what evidence rules out omitted windows.

Put the Collection Layer Into Practice

Choose the Scrapeless collection capability that matches your source, then apply the validation and operating decisions described above.

Sign up today and get $5 in free credit — no credit card required.

Claim Your $5 Credit →

FAQ

Is cursor pagination always consistent?

No. A cursor can mark a position without freezing the collection. Consistency depends on ordering stability and the server's documented snapshot or live-view behavior.

Can an empty page have a next page?

Yes, some APIs allow an empty result window with a continuation token. Use the documented completion signal rather than assuming that the item count ends the collection.

Does deduplication guarantee completeness?

No. Deduplication removes repeated identities from collected output. It cannot recover records skipped because the collection moved or a page was never accepted.

Can pages be fetched concurrently?

Only when the API supports independent windows and its access policy permits that workload. A cursor chain usually requires obtaining one continuation before requesting the next window.

References