Pagination

Public list endpoints support cursor pagination for browse-style list traversal.

Scope

This contract applies to public list endpoints that return paginated data plus meta envelopes, such as users, API keys, entities, provider accounts, transfers, quotes, policies, customer webhooks, fiat accounts, and crypto wallets.

Small directory endpoints that return simple arrays rather than paginated envelopes, such as /v1/providers and /v1/rails, do not use this pagination format.

GET /v1/notifications uses the same response envelope but has different request limits and fixed ordering, described below. The cursor-scoping and snapshot guarantees below apply to standard resource lists, not the notification inbox.

Cursor flow

1. Call a list endpoint with limit and any desired documented sort or filter parameters.
2. Read meta.nextCursor from the response.
3. Call the same endpoint again with cursor=<meta.nextCursor>.
4. Keep the same endpoint, sort, direction, and filters for the whole traversal.
5. Continue until meta.hasMore is false or meta.nextCursor is null.

Response metadata

Cursor-enabled list responses include:

• meta.limit
• meta.total
• meta.hasMore
• meta.nextCursor

nextCursor is an opaque checkpoint. Clients should store it exactly as returned and should not parse or modify it.

Cursors are scoped to the full query. Reusing a cursor with a different endpoint, tenant, environment, sort, direction, or filter set is invalid.

Traversal guarantees

Cursor pagination uses a fixed snapshot window for each traversal. Records created after the first page are excluded from the remaining pages of that traversal.

Some endpoints or sort orders may also exclude records whose sort field moves past the snapshot boundary during traversal, but public list endpoints are not a complete durable synchronization contract. Updates, deletions, and mutable sort fields can still affect what later pages contain.

If you need resumable, deletion-aware incremental synchronization, treat that as a separate integration contract rather than relying on browse pagination alone.

Request parameters

Standard resource list endpoints accept:

• limit: 1–100 items; defaults to 100
• cursor
• orderBy
• order

Exception: GET /v1/notifications accepts limit from 1–50 and defaults to 25. It uses fixed newest-first ordering and does not support orderBy or order.

Some endpoints also expose documented filters. Public cursor pagination does not accept offset.