Skip to main content
List endpoints that can return a lot of rows are paginated. Today that is /v1/transactions.

Parameters

A limit above 200 is a 400 with param: "limit", not a silent clamp. Silently returning fewer rows than asked for is how pagination bugs go unnoticed for months.

Response

total is the number of rows matching your filters, not the page size.

Reading everything

At 200 per page you can read 12,000 transactions inside one minute’s burst allowance. Filter before you page. Narrowing with from and to is far cheaper than paging through everything and filtering in your own code, and it keeps you comfortably inside the rate limits. A year of transactions for most accounts is a handful of pages.

Ordering and stability

Results are ordered by booked_at descending, then by id descending. The id tiebreak means the order is stable across pages when several transactions share a date, so paging cannot skip or repeat a row that would otherwise sort ambiguously. New transactions arriving mid-pagination still shift things, as they would in any offset-paged API. For a long backfill, pass a to date so the window you are reading cannot grow underneath you.