direct — the employer's own careers page

Read straight from the employer's site. The most first-party source there is: nobody stands between the vacancy and the row. This is the largest class by a wide margin.

employer_ats — the employer's applicant tracking system

Greenhouse, Lever, Workday, SmartRecruiters, Personio, Teamtailor, Ashby, Workable, Recruitee, BambooHR, Oracle HCM and the rest. The employer publishes into the ATS; we read the ATS's own public feed. The apply link goes to the employer's ATS-hosted application, which is where a candidate would apply anyway.

government — public employment services

National employment agencies publishing on employers' behalf, where the licence permits redistribution. Currently a small share of rows.

A row carries the class twice, in two vocabularies, and this trips people up. provider_type holds the original vocabulary (employer_ats, government, direct, aggregator) and is kept so that a query written against it still resolves. source_type holds the newer, finer per-row vocabulary (ats, career_site, public_agency, aggregator, agency, unknown). The source_type filter accepts the legacy spellings too and maps them across.

provider is finer than source_type: it names Greenhouse rather than “an ATS”. That matters when you care about the shape of the data rather than its origin — description coverage, for instance, varies from about 60% to nearly 100% depending on which system published the row, and the table below shows it per provider.

This is the single most important implementation detail in the sourcing story, and it is worth understanding the difference it makes. A blacklist — “publish everything except these names” — fails open: a source added upstream on Tuesday is published on Tuesday, and nobody finds out until someone notices. An allowlist enforced as an inner join fails closed: the same source produces zero rows in the served set until it is classified.

That is why the excluded list can be printed rather than promised. It is not a statement about intent; it is a description of a column whose default is exclusion.

• adzuna
• apify_all_jobs
• apify_fantastic_jobs
• apify_job_listings
• apify_xing
• arbeitnow
• arbeitsagentur
• careerjet
• eures
• france_travail
• himalayas
• jobicy
• jooble
• landing_jobs
• remoteok
• remotive
• the_muse
• weworkremotely
• working_nomads

19 sources excluded, listed by name in /public/coverage under excluded_sources. Measured 11 September 2026, 10:52 UTC.

There are two reasons on that list and they are not the same reason.

Aggregators — the large majority

Job aggregators and marketplaces whose terms do not permit us to redistribute their inventory. We read them for our own products; nothing from them enters this ledger's served set. Republishing them would also defeat the point of the product: an aggregator's row cannot tell you where it originally came from.

Three public agencies, discovery-only since 2026-08-15

eures, arbeitsagentur and france_travail. These were published until that date and are now used for discovery only — they tell us an employer is hiring, and we then look for the vacancy at the employer. The apply link on those rows resolves to the agency's portal rather than to the employer, which does not meet the employer-direct promise this API is sold on.

This is a different category from an excluded source. The posting is genuine and the apply link is the poster's own — it is not a stale copy of somebody else's row. What it is not is the employer. A staffing agency advertising a role it is recruiting for is doing something legitimate, and a row saying so is useful; it simply is not what “employer-direct” means.

The practical reason for the default is volume. One agency with eighteen thousand listings can flood a category until search stops being useful, and the flooding is invisible unless you already know to look for it. Excluding by default and re-admitting on request puts the choice in the caller's hands rather than in the shape of the data.