One job postings API over 8 boards: endpoints, fields, and what a run costs

Last updated

Maintained by Datapika · We publish this product under the openclawai account on Apify. Product reference

A job scraper API returns live job postings as structured JSON, billed per row. Datapika's job board scraper sweeps 8 boards (LinkedIn, Indeed, Glassdoor, Google Jobs, ZipRecruiter, Naukri, Bayt, BDJobs) in one call, deduplicates across them, and charges $0.005 per job, so 1,000 postings cost $5.00 (Apify pricing, September 6, 2026). One POST to the run-sync endpoint returns rows in a single response, an MCP URL exposes the same scraper to AI agents, and every row carries 41 fields including parsed salary, company data, and the full description.

What does a job postings API actually return?

Every run writes rows to an Apify dataset, and each row is one job posting with 41 fields in a fixed schema. The core block is id, title, company, location, job_url, job_url_direct (the employer's own application link when available), site (which board the row came from), job_type, is_remote, and date_posted. Salary is parsed into salary_min, salary_max, salary_currency, salary_interval, and salary_source, so you can normalize to annual figures without regexing description text. Company enrichment adds company_industry, company_url, company_num_employees, company_revenue, company_country, company_rating, company_reviews_count, and company_logo. The description field carries the full posting in markdown or HTML when fetch-description is on, and skills, emails, experience_range, and vacancy_count are extracted where boards expose them.

Because one run can span 8 boards, each row also records search_term and matched_search_term, plus scraped_at for freshness auditing. The result is a job postings dataset you can load straight into a warehouse or vector store: one schema regardless of source, with the site field telling you where each row was found. That uniformity is the practical difference between a job scraper API and stitching together per-board scrapers with incompatible outputs.

  • Identity and links: id, title, company, location, site, job_url, job_url_direct
  • Money: salary_min, salary_max, salary_currency, salary_interval, salary_source (parsed, not regexed from text)
  • Company: industry, size, revenue, country, rating, review count, logo, description
  • Content: full description in markdown or HTML, skills, emails, experience_range, vacancy_count
  • Provenance: search_term, matched_search_term, scraped_at on every row

Which endpoints does the job scraper API expose?

The scraper runs on the Apify platform, so it inherits Apify's REST surface. The one-call pattern is POST https://api.apify.com/v2/acts/openclawai~job-board-scraper/run-sync-get-dataset-items?format=json with your input JSON in the body and an Authorization: Bearer token from a free Apify account; the response body is the dataset rows. The endpoint holds the connection up to 300 seconds and returns HTTP 408 past that, so large sweeps use the asynchronous pattern instead: start a run, poll its status, then read the dataset. The official Node and Python clients wrap both as actor.call() followed by dataset.listItems().

For AI agents, the same actor is an MCP tool. Registering https://mcp.apify.com/?tools=fetch-actor-details,openclawai/job-board-scraper in Claude, Cursor, VS Code, or Codex CLI gives the agent two tools: the scraper itself and fetch-actor-details, which returns the input schema and current price so the agent can budget before it runs. Machine-readable descriptions exist at three unauthenticated URLs: the OpenAPI spec at apify.com/openclawai/job-board-scraper/api/openapi, the input schema at apify.com/openclawai/job-board-scraper/input-schema, and the catalog-wide datapika.com/llms.txt and datapika.com/AGENTS.md files.

  • Sync REST: run-sync-get-dataset-items returns rows in one response for runs under 300 seconds
  • Async REST: start the run, poll, then read the dataset; required for large multi-board sweeps
  • MCP: one URL preloads the scraper plus fetch-actor-details into any MCP client, Apify OAuth on first use
  • No-auth discovery: OpenAPI spec, input schema, llms.txt, and AGENTS.md describe inputs and pricing to code and agents

What does it cost to pull 1,000 or 10,000 jobs through the API?

Billing is per delivered row: $0.005 per deduplicated job as of September 6, 2026, plus marginal platform events (a $0.00005 actor start and $0.00001 per dataset item, about one cent per 1,000 rows). So 100 jobs cost $0.50, 1,000 jobs cost $5.01, and 10,000 jobs cost $50.15. There is no subscription, no minimum, and no compute charge on top; a free Apify account is enough to start, and a posting that appears on three boards is billed once, not three times.

Two controls keep an unattended pipeline inside budget. maxTotalChargeUsd, appended to any REST run URL, makes the platform stop the run at that ceiling; maxResults in the input caps how many rows the scraper attempts in the first place. An agent reading fetch-actor-details can multiply price by intended rows before calling. If your workload is company-level hiring records rather than full postings, the hiring signals scanner is the budget sibling at $0.0005 per record, ten times cheaper per row, which suits lead scoring where you need to know who is hiring more than what each posting says.

  • Worked math: 100 jobs = $0.50, 1,000 jobs = $5.01, 10,000 jobs = $50.15 (job events plus start and dataset events, September 6, 2026)
  • maxTotalChargeUsd=5 on the run URL caps a run at $5.00 no matter what the input asks for
  • maxResults caps rows attempted; combine both for unattended schedules
  • Company-level alternative: hiring signals scanner at $0.0005 per record for who-is-hiring pipelines

How is this a job aggregator API rather than one scraper per board?

A job aggregator API differs from a single-board scraper in three ways, and all three live in the input and schema rather than marketing copy. First, one input fans out: up to 5 search terms run against any subset of the 8 boards with shared filters for country, remote-only, job type, posting age in hours, and easy apply. Second, results deduplicate across boards before billing, so the dataset is a set of postings, not a pile of overlapping board responses. Third, the site field plus search_term tagging means you can still analyze per-board coverage after the fact, or attribute which board surfaces a role first.

That structure is what teams actually buy an aggregator for. Recruiting and sales teams turn the output into job leads: filter for companies posting multiple senior roles in a territory, join on company_url, and route to outreach. Analysts treat the accumulated runs as a longitudinal job postings dataset for salary and demand research, since salary fields are parsed and scraped_at dates every observation. Agent builders get breadth without tool sprawl: one MCP tool answers a cross-board question that would otherwise take five tool calls and reconciliation logic the model has to carry in context.

  • One input, 8 boards, shared filters: search terms, country, remote, job type, hours_old, easy apply
  • Deduplication happens before billing; the site field preserves per-board attribution
  • Job leads workflow: filter postings to hiring companies, join on company fields, route to CRM
  • Research workflow: accumulated runs form a dated job postings dataset with parsed salary fields

How do you export the job postings dataset?

Every run's dataset is downloadable in 7 formats by switching the format parameter on the dataset items endpoint: json, jsonl, csv, xlsx, html, xml, and rss. The same formats are one click in the Apify console, so a recruiter can grab the spreadsheet while the pipeline reads JSON from the identical run. For streaming into a stack, attach a webhook that fires when a run succeeds and POSTs the run metadata to your endpoint, then fetch the new rows; or schedule the actor daily with hours_old set to 24 and treat each dataset as an incremental batch of fresh postings.

Datasets persist on Apify with retention governed by your account plan, so backfills and reruns do not need local storage discipline on day one. For warehouse loads, jsonl is the friction-free choice for BigQuery and Snowflake; for sharing with non-technical stakeholders, xlsx preserves column order from the schema. The output schema is stable across boards, so a loader written against one run keeps working when you add ZipRecruiter or Naukri to the next run's input.

  • Formats: json, jsonl, csv, xlsx, html, xml, rss via the dataset items endpoint or console
  • Automation: webhooks on run success, plus schedules for daily hours_old=24 incremental pulls
  • Warehouse loads: jsonl into BigQuery or Snowflake with a stable 41-field schema
  • Same run serves both audiences: JSON for the pipeline, xlsx for the hiring manager
Job scraper API surfaces: what each endpoint returns and what it costs, as of September 6, 2026
Endpoint / surfaceWhat it returnsCost
POST https://api.apify.com/v2/acts/openclawai~job-board-scraper/run-sync-get-dataset-items?format=jsonDeduplicated job rows as JSON in one response (runs under 300 seconds)$0.005 per job + ~$0.01 platform events per 1,000 rows
Async: POST /runs, poll status, GET dataset itemsRun object, then the full dataset; required past the 300-second sync limit$0.005 per job, same events
MCP: https://mcp.apify.com/?tools=fetch-actor-details,openclawai/job-board-scraperThe scraper as an agent tool plus schema-and-price lookup before each call$0.005 per job; Apify OAuth with a free account
Dataset export: GET dataset items with format=jsonl|csv|xlsx|html|xml|rssThe same rows as files for warehouses, spreadsheets, or feedsIncluded with the run
OpenAPI spec: https://apify.com/openclawai/job-board-scraper/api/openapiTyped request and response schema for codegen and tool-calling frameworksFree, no auth
Input schema: https://apify.com/openclawai/job-board-scraper/input-schemaField names, types, and defaults for the actor inputFree, no auth
Catalog discovery: https://datapika.com/llms.txt and https://datapika.com/AGENTS.mdPlain-text catalog with per-actor prices, run URLs, and MCP config for agentsFree, no auth
Budget sibling: openclawai/indeed-ziprecruiter-scraper (hiring signals scanner)Company-level hiring records for lead scoring rather than full postings$0.0005 per record

Sources you can inspect

Product documentation and implementation references. These references describe supported options and billing, not independent proof of performance. Confirm current details before running; examples and estimates are not guarantees.

How to do it

  1. 1.Create a free Apify account and copy your API token, or register the MCP URL https://mcp.apify.com/?tools=fetch-actor-details,openclawai/job-board-scraper in your agent and complete OAuth once.
  2. 2.POST your input (up to 5 search terms, boards, country, filters like hours_old or remote) to https://api.apify.com/v2/acts/openclawai~job-board-scraper/run-sync-get-dataset-items?format=json&maxTotalChargeUsd=5 with an Authorization: Bearer header.
  3. 3.Read the rows from the response, or for sweeps that may pass 300 seconds, start the run asynchronously and fetch the dataset when it succeeds; export jsonl or csv for warehouse and spreadsheet consumers.
  4. 4.For recurring feeds, add a daily schedule with hours_old set to 24 and a webhook on run success, so each batch contains only fresh postings.
Run a search

Questions, answered

Is there a free job postings API?

Fully free and unlimited, no. The pattern that gets closest is pay-per-row with no subscription: a free Apify account runs Datapika's job board scraper at $0.005 per job, so a 100-job test costs $0.50 and a serious 10,000-job sweep costs about $50 (September 6, 2026). Apify accounts also include a small monthly platform credit that can cover first experiments. Free-tier SaaS offers exist elsewhere but cap records and require a vendor account; per-row billing scales down to zero when you run nothing.

Can I use a job scraper API to generate job leads?

Yes, and it is one of the two main workloads. Each row carries company, company_url, company_num_employees, company_industry, and location alongside the posting, so filtering for companies with multiple open senior roles in your territory turns a run into a job leads list ready for a CRM join. If you only need company-level signal rather than full postings, the hiring signals scanner returns hiring records at $0.0005 each, ten times cheaper per row, and pairs well with the full scraper for enrichment.

How fresh are the postings the API returns?

The scraper reads the boards live at run time, and the hours_old input filters to postings published within the last N hours, so a daily schedule with hours_old set to 24 yields only new postings each day. Every row includes date_posted from the board and scraped_at from the run, so you can audit freshness per record. There is no cached corpus behind the API: if a posting went up an hour ago and the board displays it, a run now can return it.

What formats can I export the job postings dataset in?

Seven: json, jsonl, csv, xlsx, html, xml, and rss, all from the same dataset by changing the format parameter, or one click each in the Apify console. jsonl is the usual choice for BigQuery or Snowflake loads, csv and xlsx for recruiters and analysts, and rss if you want new postings in a feed reader. The 41-field schema is identical across all 8 boards, so exports from different runs concatenate cleanly into one job postings dataset.

What is the difference between a job scraper API and a job aggregator API?

A job scraper API reads one source live; a job aggregator API merges many sources into one response. This actor is both: it scrapes 8 boards at run time, then deduplicates before billing, so a posting on LinkedIn, Indeed, and Glassdoor becomes one $0.005 row tagged with its sources rather than three rows from three tools. You get aggregator convenience (one schema, one bill) without an aggregator's staleness, since rows come from a live read, not a warehouse refreshed on the vendor's clock.

Do I need API keys for LinkedIn, Indeed, or the other boards?

No. None of the 8 boards issues a public read API key anyway, and the scraper does not log in to any of them; it reads public listings. The only credential is your Apify API token (or a one-time OAuth for MCP clients), which authenticates billing, not board access. That removes the usual failure mode of jobs integrations, where a partner key gets revoked or a program closes. Board-side blocking is handled by the platform, and you are only billed for rows actually delivered.

Keep reading