Pagination and Filtering

List endpoints use query parameters to keep responses predictable as your transaction history grows. Filters are applied before pagination, and results are generally returned newest first unless the endpoint says otherwise.

Basic request

GET /v1/transactions?page=1&limit=20&status=success
Authorization: Bearer sk_live_xxxxx

Pagination response

{
  "data": [],
  "meta": {
    "page": 1,
    "limit": 20,
    "total": 95,
    "total_pages": 5
  }
}

Common query parameters

Parameter	Purpose
`page`	Page number, starting from `1`
`limit`	Number of records requested per page
`status`	Restrict results to a resource status
`date_from`	Include records created on or after this date/time
`date_to`	Include records created on or before this date/time
`search`	Endpoint-specific text search

Some endpoints also support lookup filters such as id, uid, reference, trx_id, and email. Check the product page before relying on a filter.

Date filters

When supported, date-only values are expanded to the full day:

date_from=2026-07-08 becomes 2026-07-08 00:00:00
date_to=2026-07-08 becomes 2026-07-08 23:59:59

Use full timestamps when your reconciliation window starts or ends at a specific time.

Fetching one resource

Many list endpoints switch to single-resource mode when you provide a unique identifier:

GET /v1/transactions?trx_id=order_001

In that mode, data is usually an object instead of an array and meta is omitted. Avoid combining a unique identifier with pagination parameters.

Traversal guidance

read meta.total_pages instead of calculating against a hard-coded page size
stop when the requested page reaches total_pages or data is empty
keep filters unchanged while traversing subsequent pages
expect new records to change later pages in active datasets
use a date window during reconciliation to reduce movement between pages