Skip to main content
Batch job search runs one asynchronous job and delivers the entire result set as a single file. Where Search Jobs returns one cursor page per call, a batch job walks every page for you and returns all listings for the companies you name.
Retrieve every job listing in the dataset for up to 10 companies in a single asynchronous job. Records in the downloaded file are flat, identical to the non-batch Search Jobs record shape.
  • Companies, not filters. Provide a crustdata_company_ids list — a JSON array of integers (a comma-separated string is rejected). The job returns all listings for those companies. To search listings by arbitrary filters, use the non-batch Search Jobs instead.
  • Up to 10 companies per job. More than 10 IDs returns 400. Resolve IDs from a name, domain, or profile URL with the free Company Identify endpoint.
  • Whole result set. The job paginates server-side and delivers every listing — there is no max_results or cursor control.
  • Flat records. Each line in the results file has exactly the non-batch Search Jobs record shape. No envelope.
  • Exact field projection. When you pass fields, each record contains exactly those dotted paths — nothing more. Omit fields to get every field your account can read. The selectable fields are the same as non-batch Search Jobs.
The response is a ticket, not the listingsstatus: "pending" means the job is queued. Poll it with GET /batch/{batch_id} until status reaches completed, then download the results file, as described in Working with batch jobs below. (Search jobs always report identifier_count: 1 — the one submission.) To keep each record small, project just the fields you need:
Request body — and URL only
When the job completes, the downloaded file has one flat JSON record per line — exactly the fields you requested:
The results file (title and URL only)

Errors

400 — no company IDs
400 — comma-separated string instead of a JSON array
400 — more than 10 company IDs


What to do next