GET /v1/payment-intents, GET /v1/reconciliation-cases, GET /v1/api-keys, GET /v1/audit-events, GET /v1/outbound-webhook-events, and similar β use offset-based pagination with two query parameters.
Query parameters
Number of items to return. Minimum
1, maximum 100. Default varies by endpoint β most list endpoints default to 25; GET /v1/audit-events and GET /v1/api-keys default to 50. Check the endpointβs reference page for its exact default.Number of items to skip from the start of the result set. Minimum
0.Response shape
Every paginated list endpoint returns the same envelope:The page of results. Each itemβs shape depends on the endpoint (e.g. a
PaymentIntent summary, a ReconciliationCaseSummary, an ApiKeySnapshot).Total number of items matching the requestβs filters, across all pages β not just the current page.
Echoes the
limit used for this request (after defaulting).Echoes the
offset used for this request.Traversing all pages
Incrementoffset by limit until offset >= total:
Filtering combined with pagination
Most list endpoints accept additional filter query parameters alongsidelimit and offset β for example GET /v1/payment-intents accepts status and externalReference, and GET /v1/reconciliation-cases accepts status, reconciliationStatus, and externalReference. total reflects the count after filters are applied, so traversal logic works the same way whether or not youβre filtering.
Sending an out-of-range
limit (e.g. above 100) or a negative offset returns 400 invalid_request with an issues array β see Errors.Next steps
- Errors β validation error shape for out-of-range pagination parameters.
- Rate limits β limits that apply while paging through large result sets.
- Reconciliation cases: list reconciliation cases and Payment intents: list payment intents for concrete examples.
