Sources & ATS coverage

Every posting carries a source naming the board it was ingested from, and every id is prefixed with it:

{ "id": "ashby:7c1f2a94-…", "source": "ashby" }

source is also a filter on /v1/jobs — an exact, case-sensitive match, comma = OR — and exclude_source takes the same values to filter platforms out. The filter takes the public slug, which matches the keys of /v1/meta.sources exactly.

The live values#

curl "…/v1/jobs?source=lever"      # ✓ — the slug; payloads read "source": "lever" too
curl "…/v1/jobs?source=lever.co"   # ✓ — stored value, still accepted as input
curl "…/v1/jobs?source=Greenhouse" # ✗ — 0 rows, case-sensitive

These are every value source takes, and every one of them returns rows. There is no second tier: a platform we can read is in this list, and a platform that stops returning rows leaves it rather than lingering as a value that matches nothing. Each has a page under /ats describing what its boards look like and what the adapter reads.

adp · amazon · apple · applicantpro · applitrack · ashby · bamboohr · breezy · careerplug · comeet · cornerstone · dayforce · deel · dover · eightfold · firststage · freshteam · gem · gohire · google · greenhouse · hibob · hirebridge · hirehive · hireology · hiringthing · homerun · ibm · icims · isolved · jazzhr · jobscore · jobvite · join_com · kula · lever · linkedin · manatal · microsoft · oracle · pageup · paycom · paycor · paylocity · peopleadmin · personio · phenom · pinpoint · polymer · recruitee · recruiterbox · rippling · rival · smartrecruiters · successfactors · taleo · teamtailor · tiktok · trinet · uber · ultipro · werecruit · workable · workday · ycombinator · zohorecruit

Volume by source#

Counts are a snapshot and move hourly, and they are wildly uneven. The largest sources:

The shape worth knowing is that it is heavily skewed: the top five sources are more than half the dataset, and the tail runs down to three figures — trinet, applicantpro and taleo are hundreds of postings each, not tens of thousands.

That skew is not a quality signal. A source's size reflects how many companies use that ATS and how reachable its boards are — nothing else. SmartRecruiters being five times Y Combinator says nothing about which produces better data for you, and in one measurable respect it says the opposite: ycombinator carries a salary on 80% of its postings against a dataset-wide 36%.

Where postings come from#

Postings are read from employers' own job boards — the Greenhouse or Ashby instance a company runs for itself — rather than bought from an aggregator. 65 board adapters cover the platforms those boards run on, plus LinkedIn, which is search-based rather than a board adapter.

That "rather than bought from an aggregator" is a deliberate exclusion, not a gap in coverage. Adapters exist for the big remote boards and government feeds, and they work — they're switched off because an aggregator is many employers in one undifferentiated pool, and pooling them back together is the problem this API exists to solve. What you get instead is the employer's own board, which is where apply_url becomes worth something.

Multi-tenant ATS#

Platforms hosting boards for many companies. These are the bulk of coverage: one adapter reaches thousands of employers.

adp · applicantpro · applitrack · ashby · bamboohr · breezy · careerplug · comeet · cornerstone · dayforce · deel · dover · eightfold · firststage · freshteam · gem · gohire · greenhouse · hibob · hirebridge · hirehive · hireology · hiringthing · homerun · icims · isolved · jazzhr · jobscore · jobvite · join_com · kula · lever · manatal · oracle · pageup · paycom · paycor · paylocity · peopleadmin · personio · phenom · pinpoint · polymer · recruitee · recruiterbox · rippling · rival · smartrecruiters · successfactors · taleo · teamtailor · trinet · ultipro · werecruit · workable · workday · zohorecruit

Single-company#

Employers large enough to run bespoke career sites that need their own adapter. There is no "many boards" problem here — there is one site, and it breaks on its own schedule:

amazon · apple · google · ibm · microsoft · tiktok · uber

Job boards#

A posting here was published to a board or collected by one, not to a company's own careers page — which changes what apply_url points at. There are two, and they earn the exception for opposite reasons:

ycombinator · linkedin

Y Combinator's Work at a Startup is a board per company rather than one pooled feed, which makes it behave like an ATS even though it isn't one.

LinkedIn#

Search-based rather than a board adapter, and refreshed as an hourly delta of the last hour's postings. It's the fourth-largest source and the largest that isn't an employer's own board — which is worth knowing when you read apply_url on a linkedin posting.

Boards tracked per provider#

The ingestion queue tracks 108,389 individual company boards. The twenty largest queues:

Boards, not postings — one board is one company's careers page, holding anywhere from zero to several thousand open roles.

A tracked board is not a guarantee of postings#

Tracking a board means knowing it exists and attempting it on a schedule. Postings appear only if the board is reachable, still live, and currently advertising something — and boards go quiet: a company freezes hiring, migrates ATS, or takes its board down. Boards that fail five consecutive times are disabled automatically. So a provider's board count is an upper bound on where its postings could come from, never a promise of how many you'll get.

The reverse holds too, and it is the more useful lesson: bamboohr leads on boards tracked while smartrecruiters has a fraction of the boards and an order of magnitude more postings. Board count and posting count measure different things — BambooHR is popular with small companies that have few open roles at a time.

The practical rule: /v1/meta is the only authority on what you can filter on. This page explains what the values mean; /v1/meta says which exist right now.

Attribution and provenance#

Because postings come from employers' own boards, apply_url is the employer's real application form — the same URL a candidate would reach from the company's careers page. It isn't a redirect, a tracking wrapper, or an aggregator's mirror.

Two consequences:

• Applications land in the employer's ATS. Sending a candidate to apply_url puts them in the real pipeline, not a queue that forwards later.
• apply_url falls back to url. When a board publishes no distinct apply link, the two fields are identical. See derivations.

That distinction is queryable: every posting carries a source_type — ats (a board the employer authors and manages applicants on), jobboard (third-party boards like LinkedIn or Wellfound), or aggregator (re-listing sites) — and ?source_type= filters on it, comma = OR. Some providers sell this split as two separate products: an "ATS jobs" endpoint and a "job board jobs" endpoint, each with its own schema, because their pipelines never merge the populations. Ours do merge — cross-source mirrors are folded by dedup — so provenance is one filter on one schema rather than two endpoints. One classification worth knowing: join.com counts as ats — the employer authors the posting and manages applicants there, which is the property source_type measures. (Dedup priority is a different question with a different answer: a join.com copy still loses to the employer's Greenhouse board when both exist.)

The same job posted to several boards is collapsed to one row rather than returned five times, so source tells you which copy survived deduplication — not the only board the job ever appeared on.

Related#