ATS Jobs Scraper

Read a company's open positions straight from the applicant-tracking system it actually hires through. Greenhouse, Lever and Ashby all publish their job boards openly, so this reads structured data rather than parsing a page.

Give it a company name or a pasted board URL. No API key, no login.

Why this is different from scraping a careers page

The three systems each expose a documented public job-board endpoint. That has two consequences worth knowing before you compare this with a page scraper:

It does not break when a site is redesigned. There is no markup to parse, so a careers-page facelift changes nothing here.

It returns everything at once. Stripe's board came back with 619 open positions in a single request. A page scraper would walk that in twenty paginated fetches.

You do not need to know which system a company uses

Type stripe and all three are tried until one answers. If you already know, pin it with greenhouse:stripe, lever:matchgroup or ashby:Ramp, or just paste the board URL you were looking at.

A company that is on none of the three is reported as exactly that, rather than as an empty result you would have to interpret.

What each job gives you

• title, url and apply_url
• company, board and ats — which system published it
• location, plus all_locations when a posting lists several, and country
• department and team
• employment_type (full time, contract), workplace_type (onsite, hybrid, remote) and is_remote
• published_at and updated_at
• description as plain text, plus description_chars
• salary — see below

description_chars is more useful than it looks: a posting with 200 characters is a stub, and one with 4,000 is a real spec. Sorting by it separates the two without reading any of them.

Three payload details this gets right

Greenhouse escapes its own HTML. Its description field arrives as <h2><strong>Who we are rather than as markup. A parser that strips tags without unescaping first leaves every entity code in place, and the description reads as soup. It is unescaped once, then stripped.

Lever timestamps are milliseconds. createdAt is a number like 1787203369315. Read as seconds that is the year 58,000. Read correctly it is 2026. A date that wrong still sorts and still renders, which is exactly what makes it dangerous.

The three publish three different date formats — an offset timestamp, a millisecond integer and a Zulu time with milliseconds. Left alone, sorting a mixed run by date compares those strings against each other and quietly gets the order wrong. Everything is converted to one UTC form.

About salary

Only Ashby publishes pay on its public board. Its postings carry a ready-made range such as $211.4K – $290.6K • Offers Equity. Greenhouse and Lever carry nothing equivalent.

So an empty salary means this system does not publish pay, not that the job is unpaid. The run summary reports withSalary so you can see how much of a run carried one rather than assuming.

Filters

• Title contains — engineer, designer
• Location contains — london, remote, new york
• Remote only — postings flagged remote by the system or listing a remote location
• Include full descriptions — on by default. Lever and Ashby always include the text; for Greenhouse it means a larger response, so turn it off when you only need titles and locations.

Run summary

Boards requested and read, a count per system, jobs returned, how many carried pay and a description, how many are remote, and the number of distinct companies and departments.

The per-system breakdown is the useful health check: if a run of twenty companies reports jobs from only one system, the other names were probably wrong rather than empty.

What people use this for

Recruiting intelligence. Which teams a competitor is growing, and how fast, is visible in the department breakdown across repeated runs. published_at turns that into a hiring-velocity series.

Pay benchmarking. The Ashby subset is a genuine sample of published ranges by role and location, which very few sources give you in structured form.

Job aggregation. One request per company, everything normalised into one shape, so a board of a hundred companies is a hundred requests and one table.

Lead scoring. A company that just opened fifteen engineering roles is hiring, and hiring is a buying signal if you sell to engineering teams.

Scale

Each board is exactly one request regardless of how many openings it holds. Three companies across all three systems returned 838 jobs in 22 seconds in testing, 138 of them with pay and 836 with full descriptions.

Because there is no pagination and no per-job follow-up, a run of fifty companies is fifty requests.

Notes

Only currently open positions appear. A role that is filled or withdrawn stops being published, so running on a schedule and keeping the rows lets you see how long postings stay open, which is a fair proxy for how hard a role is to fill.

Board names are case-sensitive on Ashby (Ramp, not ramp) and lower-case on Greenhouse and Lever. Pasting the URL avoids the question entirely.