Skip to main content
List endpoints return results in pages. When your request matches more records than one page holds, the response includes a next_page_url — follow it to get the next page, and keep going until the field disappears.

How it works

Request income statements with limit=25:
The response contains the first page of statements plus a link to the next page:
Request the next_page_url exactly as given — it is self-contained, no other parameters needed. The final page has no next_page_url field, which is your signal to stop.

The loop

The same loop works on every list endpoint — only the array key changes (prices, filings, insider_trades, news, and so on).

The cursor

next_page_url carries an opaque cursor token that encodes your original request — its filters, and where the last page ended.
  • Treat it as opaque. Do not construct, modify, or store cursors long-term; get them from next_page_url only.
  • Other parameters are ignored alongside a cursor. The cursor already carries your original filters, so filters cannot change mid-walk. To change filters, start a new request without a cursor.
  • Cursors are endpoint-specific. A cursor from /prices will not work on /filings.
A modified or foreign cursor returns 400:

What limit means

limit is the total number of records you want; pagination just delivers it across as many pages as needed. A request small enough to fit in a single page returns no next_page_url at all.

Billing

Each page is a standard API request and is metered as one.

Which endpoints paginate

All endpoints that return a list of records: financial statements (including segments and as-reported), financial metrics, prices, filings, earnings, news, KPIs, insider trades, insider ownership, beneficial and activist ownership, institutional holdings, index funds, and IPOs. Endpoints that return a single object — company facts, snapshots, interest rates — and /filings/items (the sections of one filing) always return their full result.