Which methods paginate
Cursor vs page is an implementation detail — the SDK exposes the same interface for both. Cursors are stable even if new records are added between calls, so you won’t see duplicates.
Stream every result
Iterate the returned page to walk every match across all pages. Each page is fetched on demand, through the client’s rate limiter.Bound how much you pull
max_items is a client-side total cap — it stops the SDK fetching once reached and is never sent on the wire. Use it (with max_results tuned for page size) to keep spend predictable.
Per-page and manual control
Take the first page, inspect totals and cursors, and fetch the next page yourself when you need explicit control (your loop, your spend).Page object shape
- Python — items are on
page.results; cursor onpage.cursor. The page types (CursorPage,PageNumberPage, and theirAsync*variants) are exported fromblitz_api. - TypeScript — items are on
page.data; the full parsed response (snake_case, 1:1 with the API — e.g.total_results,page,total_pages) is onpage.response.
Next steps
Rate limits & retries
How the client-side limiter and automatic
429/5xx retries work.Python SDK
Full method reference for
blitz-api-py.TypeScript / JavaScript SDK
Full method reference for
blitz-api-js.API reference
Request/response schemas and a try-it console.

