Skip to main content
This page covers two asynchronous batch endpoints:
  • Batch search — results served from the indexed database, higher caps and faster (up to 10,000 records).
  • Batch live search — results retrieved from the web in real time, fresher but capped lower (up to 1,000 records).
Batch live search is available on the live plan. The Batch live search section below documents its gating and behavior.

Batch search runs one query asynchronously and delivers the entire result set as a single file. Where Company Search returns one cursor page per call, a batch job walks every page for you.
For fresher results retrieved from the web in real time, see Batch live search below.
  • One query, whole result set. You submit a single query; the job paginates server-side until max_results is reached or the matches run out.
  • max_results is the only volume control. It clamps to 10,000 and defaults to that cap when omitted. Values above the cap are silently clamped; zero or negative values return 400. The non-batch paging knobs — limit, page, preview — are silently ignored.
  • Flat records. Each line in the results file has exactly the non-batch search record shape. No envelope.
  • Exact field projection. When you pass fields, each record contains exactly those fields — nothing more. Omit fields to get every field your account can read.

POST /batch/company/search takes the same filter fields and operators as Company Search, with one extra rule: the top level of filters must be an {op, conditions} group — a bare {field, type, value} condition is rejected with 400. Groups nest inside conditions for complex queries. This finds companies with more than 1,000 employees:
Search jobs always report identifier_count: 1 — the one query. When the job completes, the downloaded file contains flat records with exactly the requested fields:
The results file (all records)

Two warnings before you submit large jobs

Unknown filter field names are not rejected at submit time the way non-batch search rejects them — a typo in field simply produces a job that completes with 0 results. Double-check field names against the search reference first.
Do not pass a non-empty sorts array — the job will complete with 0 results. Sort the downloaded file instead, for example jq -s 'sort_by(.headcount.total) | reverse | .[]' results.jsonl.


Errors

400 — no filters
400 — invalid max_results

Batch live search is available on the live plan.
Batch live search runs one query asynchronously and delivers the entire result set as a single file, with results retrieved from the web in real time. Where Company Live Search returns one cursor page per call, a batch job walks every page for you.
For results served from the indexed database — higher caps and faster — see Batch search above.
  • One query, whole result set. You submit a single query; the job paginates server-side until max_results is reached or the matches run out.
  • max_results is the only volume control. It clamps to 1,000 and defaults to that cap when omitted. Values above the cap are silently clamped; zero or negative values return 400. The non-batch paging knobs — limit, page, preview — are silently ignored.
  • Flat records. Each line in the results file has exactly the non-batch search record shape. No envelope.
  • Exact field projection. When you pass fields, each record contains exactly those fields — nothing more. Omit fields to get every field your account can read.

POST /batch/company/professional_network/search/live retrieves results from the web in real time — fresher than the database, capped at 1,000 records per job, fetched internally in pages of 25, and slower. Live jobs are the most likely to end failed with an error_message. Live filters use a flat list of {field, type, value} objects — not the {op, conditions} group — and field takes an uppercase filter type instead of a dotted path:
The results file (all records)
Valid filter types: INDUSTRY, COMPANY_HEADCOUNT, REGION, COMPANY_HEADQUARTERS, ANNUAL_REVENUE, NUM_OF_FOLLOWERS, FORTUNE, DEPARTMENT_HEADCOUNT, DEPARTMENT_HEADCOUNT_GROWTH, COMPANY_HEADCOUNT_GROWTH, KEYWORD_COMPANY, ACCOUNT_ACTIVITIES, JOB_OPPORTUNITIES — the same filters as the non-batch Company Live Search, which documents per-filter value formats. An unknown filter type returns 400 listing the valid values. Company filters additionally support the between match type with an object value and an optional sub_filter qualifier:
A between filter
Instead of filters, you can replay a saved company search URL:
Request body
Provide either filters or professional_network_search_url — omitting both returns 400.

Errors

400 — neither filters nor a search URL
400 — invalid max_results

What to do next