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.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 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.

