Pagination

Lists take page and limit:

Parameter	Default	Range
`page`	`1`	from `1`
`limit`	`20`	`1` to `100`

Each response returns the records in data, with:

Field	Meaning
`page`, `limit`	The page you asked for.
`total_count`	How many records match.
`total_pages`	How many pages that makes at this `limit`.
`has_more`	Whether there is a next page. Keep reading until it is `false`.
`total_is_capped`	`true` when the list stopped counting. See below.

Pass limit=100 when you read a whole list. It needs five times fewer requests than the default.

Ordering

Lists that support it take sort: a field name for ascending order, or the name with a - prefix for descending. Ties break on id. Without sort, a list is in id order, with these exceptions:

Transactions come newest captured_at first.
Products come in code order.
A device's applications come in name order, and take no sort.
A sync request with updated_after comes in updated_at order.

GET /integration/v1/tradings?sort=-updated_at&limit=100

sort=-updated_at returns the records changed most recently first. To keep a copy of enterprises, companies, tradings or acquirers up to date, use sort=updated_at with updated_after instead. See Syncing data.

The 10,000 record limit

Some lists stop counting at 10,000. On those lists:

total_count reads 10,000, with total_is_capped: true.
A request where page × limit is over 10,000 returns 400, with page named in invalid_params.

Trading enrollments are the exception: has_more turns false at 10,000.

To reach records beyond 10,000, add filters.

Lists	Limit
Enterprises, companies, tradings, devices, products, a device's applications	None. You can read them to the end.
Acquirers, applications, trading enrollments, transactions, device models	Stop at 10,000.

OrderingCopy Anchor Link

The 10,000 record limitCopy Anchor Link

On this page

Ordering

The 10,000 record limit