blitz-api-js is the official, typed TypeScript SDK for BlitzAPI. It is fetch-based, Zod-validated, ships both ESM and CommonJS builds with .d.ts / .d.cts types, and uses snake_case request and response fields that match the API reference exactly. Retries, client-side rate limiting per endpoint and auto-pagination are built in.
npm
blitz-api-js on the npm registry.GitHub
Source, changelog, and issues.
Install
fetch). Ships both ESM and CommonJS builds.
Quickstart
Authentication
Pass the key explicitly or via theBLITZ_API_KEY environment variable. It is sent in the x-api-key header on every request.
Endpoints
All methods are grouped into seven namespaces. Each takes a single options object (snake_case keys) and returns a typed, Zod-validated response. The seven list methods (search.people, search.companies, search.employee_finder, jobs.search, jobs.company, company.tam_by_jobs, company.tam_by_people) return a paginated PagePromise (see Pagination); waterfall_icp, changelog.list, and the enrichment / utils / account methods return their response directly.
client.account
client.search
client.jobs
client.company
client.enrichment
client.utils
client.changelog
Pagination
The list methods (search.people, search.companies, search.employee_finder, jobs.search, jobs.company, company.tam_by_jobs, company.tam_by_people) return a PagePromise: await it for the first page, or for await to stream every item across all pages (each fetched on demand).
max_items, .collect(), manual paging, page metadata, and how each result counts as a record.
Usage & rate limit
Every metered/v2 response carries a fair_usage block reporting the records the request used and what is left, so you can meter a batch job without a second key_info() call.
changelog.list(), which is not metered, doesn’t return the block. account.key_info() returns it with records_used at 0 and no rate_limit, since that endpoint is not rate limited. Every field is optional, so a response predating the block still parses.
Configuration
429; see Rate limits & retries. rate_limit_rps defaults to 5; set it to your key’s max_requests_per_seconds to use your plan’s full per-endpoint throughput.
Error handling
401 / 402 / 404 throw immediately; 429 and 5xx are retried automatically; timeouts surface as APITimeoutError (not retried). A 401 with a valid key means the endpoint is not in the key’s allowed_apis (“You do not have access to this route”); read allowed_apis from client.account.key_info(). FairUsageLimitError is still exported as a deprecated alias of InsufficientRecordsError (the same class, not a subclass) and is scheduled for removal in 4.0.0, so existing instanceof checks keep working for now; err.name is already "InsufficientRecordsError". See Rate limits & retries for the full retry and timeout behavior.
A 400 or 422 also throws immediately, as APIStatusError. For a 422, err.body.errors lists each invalid field as { field, message }; see Errors. The API rejects any field it does not define, so an extra key in a params object returns a 422 even when TypeScript does not flag it.
Types & enums
Response objects keep their snake_case wire keys and preserve unknown fields: if the API adds a property before this SDK models it, the value is still present (typed asunknown); known fields stay precisely typed.
industry, job_level, continent) accept a known value (autocompleted from a union like Industry) or any raw string, so a value missing from the vendored taxonomy never blocks you.
Next steps
Python SDK
The same API surface with sync + async clients.
Field Normalization
Accepted values for industry, job level, job function, and geography filters.
API reference
Full request/response schemas and an interactive try-it console.
Recipes
End-to-end workflows: build an ICP list, enrich it, and sync to your CRM.

