Skip to main content
Agents & LLMs: a Markdown version of this page is available by appending .md to the URL, and the full documentation index is at llms.txt.
In the BlitzAPI SDKs, the list methods return an auto-paginating page. Iterate it and the SDK fetches each subsequent page for you, with no cursor or page bookkeeping. Each result returned counts as one record, so bound the loop with max_items or page manually. This works identically in Python and TypeScript; only the syntax differs.

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.
company.tam_by_jobs and company.tam_by_people pages carry no total_results (the API omits it for TAM), so iterate until the cursor is null. job.min_per_company (or people.min_per_company) can also make a page come back partial: keep paging rather than stopping on a short page.

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.
max_results is the page size (1–50), not a total, and each result returned counts as 1 record against your fair use policy. A bare loop streams every match up to the server-side cap (people / companies: 50,000 results or 1,000 pages; TAM by jobs / TAM by people: 50,000 companies; employee finder: 10,000; jobs: 5,000). The page that reaches the cap looks like a normal end of results. Bound it with max_items, break out of the loop, or drive pages manually (below).

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 the records counted against your fair use policy 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 over the loop and the records it uses.

Page object shape

  • Python: items are on page.results; cursor on page.cursor. The page types (CursorPage, PageNumberPage, and their Async* variants) are exported from blitz_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 on page.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.