External hiring data for workforce planning, compensation reviews, and peer benchmarking
Internal HR analytics tools are good at telling you what's happening inside your company — headcount, attrition, time-to-fill. They're blind to what's happening outside it. CleanJobData fills that gap with one row per open job at the employers you compare yourself to: title, seniority, location, work arrangement, posted pay, and when it was posted and closed. People Analytics teams sync it into a warehouse and join it against their own headcount and comp data; HR-tech vendors use it to add a market benchmark to their product. Either way, compensation reviews, headcount plans, and location decisions get checked against what peers are posting now, not last year's survey.
Run real queries in the playground without a key, or start a 14-day free trial with 300 requests a day. No card required.
Yes. For one company, filter by company_website_url (e.g. `?company_website_url=competitor.com`), which matches the employer's own domain rather than the ATS host. For a list of peers, collect their employer_id values and pass them comma-separated, up to 100 per request. You get their current open roles, seniority mix, and posted salaries. Store each pull with a date and you have a time series of each peer's hiring.
Yes — combine title, city_id, and experience_level, e.g. `?title=staff+engineer&city_id=<sf_id>&experience_level=SE`, to pull current posted salary ranges for that exact combination. Add `salary=<floor>&require_salary=true` to drop listings without disclosed pay. Use it alongside your existing comp survey data as a live cross-check, not as a replacement — postings show what employers offer to attract candidates now, which is a different signal than what incumbents are paid. Salaries are in the employer's currency with no pay-period field, so convert and sanity-check before mixing markets.
published_after sets a lower bound on the posted date, and there's no upper-bound date filter, so the most reliable approach is to keep your own history. Run a daily sync with created_max_age=1d into your warehouse, mark closed jobs from GET /jobs/expired, and compare periods with SQL on your own tables. For a one-off look back, `?employer_id=<id>&published_after=2026-07-01T00:00:00Z&include_expired=true&count=true` counts everything a peer posted since July 1, open or closed.
There's no native connector. The API returns JSON, so the usual setup is a scheduled job (cron, Airflow, or n8n) that loads it into Postgres, BigQuery, or Snowflake, with your BI tool reading from there. That also keeps your request count low: dashboards query your tables, not the API. The pattern is in /guides/syncing-job-data-in-depth.
For weekly or monthly reporting, Starter is usually enough: 50,000 requests a month at up to 50 jobs each, and new jobs 24 hours after we index them, which doesn't matter for a quarterly comp review. Choose Pro if you need new postings the day they're indexed or more volume (100,000 requests, up to 100 jobs each). Both licenses cover an internal HR tool. Passing raw listings on to third parties, for example as a data feed inside a product you sell, needs an Enterprise license (see /enterprise).
This use case is about benchmarking your own org against specific named competitors and peers for internal HR decisions. The Labor Market Data API use case is for aggregate market/industry research across many employers — economic trend analysis rather than company-level benchmarking.
