Every major applicant tracking system — Greenhouse, Lever, Ashby and Workday — exposes a public, unauthenticated job feed. These feeds exist so companies can power their own careers pages, but job platforms read them to import listings at scale. Greenhouse is the friendliest, with one request returning a whole job board; Lever returns a bare JSON array; Ashby adds structured salary data; and Workday is the odd one out, needing POST requests with JSON bodies. Understanding these four feeds is the foundation of any ATS integration.
Why the feeds exist in the first place
An ATS (applicant tracking system) is the software companies use to manage hiring — posting jobs, collecting applications and tracking candidates. Almost every employer's careers page is a thin skin over their ATS: the page shows a list of open roles and an apply form, and the ATS stores everything behind it.
To render those careers pages, each ATS exposes a feed — a URL that returns the company's open jobs as structured data. Because the feeds power public careers pages, they are stable, usually undocumented-but-open, and legal to read. This is why ATS feeds, rather than fragile page scraping, are the correct integration route: they change rarely, they carry clean fields, and they update the moment a recruiter publishes or closes a role.
Greenhouse: the friendliest feed
Greenhouse offers the smoothest public integration of the four. One GET request to its boards API returns the entire job board of a company — every open posting in a single response. Add the content=true flag and the full job description comes along too, so you often never need a second request per job.
Two practical quirks to handle. First, the descriptions arrive as HTML with double-encoded entities, so you must decode entities and then strip the tags to get clean text. Second, Greenhouse identifies companies by a board token — a short slug like the company name — which you can find by watching where the careers page loads its data from. Once you have the token, the board is one request away.
Lever: a flat JSON array
Lever's public feed is nearly as simple. One GET request per company returns the whole board as a bare JSON array — not an object, which catches some JSON parsers off guard. The description is split into structured lists, which makes it easy to pull out sections like responsibilities and requirements separately.
Companies are identified by a slug in the URL. With the mode=json flag you get machine-readable data instead of the human-facing widget version. Lever boards tend to be small and stable, which makes them cheap to poll on a schedule.
Ashby: structured pay, if the company opts in
Ashby's posting API returns the whole job board in one GET request, like Greenhouse. Its standout feature is structured compensation: with the includeCompensation=true flag, postings include real salary fields — minimum, maximum, currency — instead of a range buried in prose.
This is rare. Most ATS feeds give you no structured pay at all, and the ones that do are the exception rather than the rule. The catch is that the company must choose to publish its pay bands; when it does not, you fall back to extracting ranges from the description text, the same as everywhere else.
Workday: the POST-based odd one out
Workday is the hardest of the four. It has no documented public API; instead, every Workday careers site is a single-page app that talks to a JSON endpoint you can call directly. The endpoint expects a POST request with a JSON body carrying the page size, offset and search text, and it returns jobs twenty at a time.
Everything about Workday pagination deserves care. The total count it returns is only correct on the first page. Dates arrive as text like "Posted Today" or "Posted 3 Days Ago" rather than real timestamps — the detail endpoint carries the true start date. Location fields can be vague, sometimes literally reading "2 Locations". Workday integrations are entirely possible, but they need more defensive code and more requests than the other three.
From four shapes to one job
No two ATS feeds agree on field names, and the shapes differ too: an object for Greenhouse, a bare array for Lever, compensation flags on Ashby, twenty-job pages on Workday. A serious integration maps every source into one canonical job record — company, source, job id, title, department, location, remote flag, employment type, posted date, salary, description text and apply URL.
Salary normalisation is its own sub-project. Only a minority of feeds carry structured pay, so the standard technique is a regex pass over the description text to catch currency amounts and ranges, with a floor to reject false positives like signing bonuses. Department and employment-type values also need mapping tables, because each ATS spells them differently.
Detecting new and closed jobs
Importing listings is only half the work; the other half is knowing what changed. The standard pattern is a seen-list: keep a map of ats:company:jobId to the date first seen. Each import run, any job not in the map is new, and any job in the map but missing from a successful fetch is closed.
That last condition matters. If a fetch times out, every job at that company would look closed — so a job is only marked closed when its company's fetch succeeded. And the very first run should be a silent baseline, or your "new jobs" feed starts with thousands of items. Run this on a schedule and you have a reliable new-jobs and closed-jobs feed for any list of companies.
Frequently asked questions
Is it legal to read public ATS job feeds?
Yes. These feeds are published by the ATS vendors specifically to power public careers pages, and they are intentionally unauthenticated. Reading them is using a published interface, not scraping behind a login wall.
Which ATS gives the most structured data?
Ashby, when the company publishes pay bands — it is the only one of the four with structured salary fields. Greenhouse is the most complete overall, with full descriptions inline in a single request.
Why is Workday harder to integrate than the others?
It has no documented public API, requires POST requests with JSON bodies, paginates at twenty jobs per page, and returns dates and locations as free text. The integration works fine, but it needs more defensive parsing.
How do you reliably detect when a job is closed?
Track every seen job by a composite key of ATS, company and job id. A job missing from a completed fetch is closed — but only mark it so when the fetch succeeded, or one timeout looks like a mass closure.
Building a hiring platform or job feed integration?
ATS integrations are the unglamorous backbone of every job platform, and the edge cases are where they are won or lost. We have built feed importers that handle millions of listings across Greenhouse, Lever, Ashby, Workday and more — normalisation, deduplication, closed-job detection and all. Talk to us about your project.
