ATS New Job Postings Monitor — Greenhouse, Lever & Ashby

This Actor monitors Greenhouse, Lever and Ashby job boards and returns new job postings as structured data. Give it a list of boards — a Greenhouse board token, a Lever company slug, an Ashby board name — and each run fetches the boards' current postings through the platforms' own public job-board APIs and writes one clean record per posting: company, job title, location, department, team, employment type, workplace type, posted date, and the job and apply URLs. Run it on a schedule with only-new mode on, and every run delivers just the postings you have not seen before, deduplicated against a state store you own. Inputs are the board lists plus optional filters (posted-within days, title keywords, location keywords, departments) and a delivery cap; there is no API key, account or login to configure, because the three platforms publish these feeds openly for exactly this kind of reuse.

What it does

Hiring is one of the strongest public signals a company sends. A company that just opened ten engineering roles is growing, has budget, and is about to buy tooling, services and office space; a company hiring its first sales leader is entering a new phase. Those signals appear first on the company's applicant-tracking system (ATS) job board — days or weeks before they show up anywhere else. This Actor turns three of the most common ATS platforms into one normalized, monitorable feed:

• Greenhouse — boards at boards.greenhouse.io/<token> (e.g. airbnb).
• Lever — company boards at jobs.lever.co/<company> (e.g. leverdemo).
• Ashby — boards at jobs.ashbyhq.com/<name> (e.g. Ramp).

Each run writes three kinds of rows to the dataset:

• posting rows — one per job posting, with the fields listed in the output table below. These are the only rows you pay for.
• error rows — one per board that could not be fetched (unknown board, HTTP error, unexpected response), with the source, board and reason. Never charged, and one bad board never stops the other boards from delivering.
• One summary row at the end of every run: the boards covered, how many postings were fetched per source, delivered, skipped as duplicates, filtered out, or failed. Never charged.

Use with AI agents / MCP

The input is deliberately minimal so an agent can call this Actor zero-shot: the board lists come prefilled with working example boards and postedWithinDays is the only required field. A minimal call looks like this:

{
  "postedWithinDays": 7
}

A filtered call — new engineering roles at three companies, remote-friendly locations only:

{
  "greenhouseBoards": ["airbnb"],
  "leverCompanies": ["leverdemo"],
  "ashbyBoards": ["Ramp"],
  "titleKeywords": ["Engineer"],
  "locationKeywords": ["Remote"],
  "postedWithinDays": 14,
  "maxPostings": 100
}

Sample output (one posting row, from a real Ashby board):

{
  "recordType": "posting",
  "source": "ashby",
  "company": "Ramp",
  "jobId": "34413f8d-26bf-4bbc-8ade-eb309a0e2245",
  "title": "Security Engineer, Cloud",
  "location": "New York, NY (HQ)",
  "secondaryLocations": ["Remote (Canada)", "Remote (US)", "Miami, FL"],
  "department": "Engineering",
  "team": "Backend",
  "employmentType": "FullTime",
  "workplaceType": "Hybrid",
  "postedAt": "2026-04-07T17:12:35.753+00:00",
  "jobUrl": "https://jobs.ashbyhq.com/Ramp/34413f8d-26bf-4bbc-8ade-eb309a0e2245",
  "applyUrl": "https://jobs.ashbyhq.com/Ramp/34413f8d-26bf-4bbc-8ade-eb309a0e2245/application"
}

Inputs

Field	Description
Greenhouse boards (prefilled ["airbnb"])	Greenhouse board tokens to watch — the segment after boards.greenhouse.io/ in a board URL. Empty list = skip Greenhouse.
Lever companies (prefilled [])	Lever company slugs to watch — the segment after jobs.lever.co/.
Ashby boards (prefilled ["Ramp"])	Ashby board names to watch — the segment after jobs.ashbyhq.com/. Empty list = skip Ashby.
Posted within days (required, prefilled 7)	Only postings dated within the last N days. 0 = no date limit. See Limitations for what "date" means per source.
Title keywords	Only titles containing at least one keyword (case-insensitive substring).
Location keywords	Only postings whose location — including Ashby secondary locations — contains at least one keyword.
Departments	Only postings whose department or team matches one of these exactly (case-insensitive). Greenhouse's public payload carries no department, so this filter excludes Greenhouse postings.
Only new postings (prefilled on)	Monitor mode: skip postings delivered by earlier runs. Requires the state store below.
Seen-postings state store	A key-value store you own where the Actor remembers delivered posting IDs (read/write). If it is missing or fails, the run continues without dedupe and the summary says so — it never crashes.
Max postings (prefilled 200)	Cap on posting records delivered (and charged).

Output fields

Field	Meaning
source, company	greenhouse, lever or ashby, and the board name exactly as you configured it.
jobId	The posting's unique ID within its source. Together, source:company:jobId uniquely identifies a posting and is the dedupe key.
title	Job title as posted.
location, secondaryLocations	Primary location as the board states it; Ashby boards also list secondary locations (other sources omit the field).
department, team	Department and team, when the source provides them (Lever and Ashby; Greenhouse's public payload has neither).
employmentType	As the source states it: Lever commitment (e.g. Regular Full Time (Salary)) or Ashby employment type (e.g. FullTime).
workplaceType	When known: Greenhouse "Workplace Type" metadata, Lever's workplace type, or Ashby's workplace type.
postedAt	When the posting first went live: Greenhouse first-published date, Lever creation date, Ashby published date. The "posted within N days" filter uses this field.
updatedAt	Greenhouse only: the posting's last-edited timestamp. Informational; never used for filtering.
jobUrl, applyUrl	The public posting page, and the direct application link when the source provides one.

Job descriptions are deliberately not included: they are long, they differ wildly in format, and a monitor feed should stay light. The jobUrl always takes you to the full posting.

Scheduling / only-new monitoring usage

This Actor is built to be scheduled. The pattern:

1. Create any key-value store in your Apify account (an empty one is fine) — this is where the Actor remembers delivered postings.
2. Run the Actor once with your boards and filters, onlyNew on, and that store selected in the Seen-postings state store input. This first run delivers the full in-window set as the baseline and records every delivered posting as seen.
3. Schedule the Actor (daily or weekly) with the same input. Each later run fetches the boards, skips anything already in the store — never delivering or charging it twice — and delivers only genuinely new postings. Postings that were filtered out or failed are not marked seen, so a later run with different filters can still deliver them.
4. Read the run's SUMMARY row to see fetched / delivered / duplicates-skipped counts per run.

If you turn onlyNew on but do not select a store, the Actor degrades gracefully: it delivers all matching postings and states explicitly in the SUMMARY record (and the run status) that dedupe was off — it never crashes and never silently pretends to dedupe.

Practical scheduling notes: a weekly run pairs naturally with postedWithinDays: 7; a daily run with postedWithinDays: 2. Boards that stop existing (a company migrates ATS) produce one error row per run and affect nothing else.

Pricing

Pay-per-event only: $0.01 per posting record delivered. There is no start fee, no charge for the summary or error rows, no charge for duplicates or filtered-out postings, and empty runs are free — if nothing matches, you pay nothing.

Apify plan	Price per posting record
FREE / BRONZE	$0.0100
SILVER	$0.0085
GOLD	$0.0070
PLATINUM / DIAMOND	$0.0070

For scale: watching the prefilled boards with a 7-day window returns a few dozen postings — well under $1 per run at list price. Cost grows only with the postings you actually receive.

FAQ

How do I find a company's board name?

Open the company's careers page. If jobs are hosted on Greenhouse, the board token is the part after boards.greenhouse.io/; for Lever it is the part after jobs.lever.co/; for Ashby, after jobs.ashbyhq.com/. Most tech companies link their ATS board directly from their careers page.

Why did my first only-new run deliver so many postings?

That is the baseline: with a fresh state store, everything in your window counts as "not seen yet". Later scheduled runs deliver only what is genuinely new.

A board returned an error row. What happened?

The board name is wrong, the company moved to a different ATS, or the platform hiccuped. The error row carries the HTTP status and a plain-language reason; fix the board name or remove it — the other boards are unaffected.

How fresh is the data?

The Actor reads each platform's public API at run time, so a posting appears in your feed on the first scheduled run after the company publishes it. Daily schedules mean day-old hiring signals at the latest.

Does this collect personal data?

No. Job postings are published by companies about roles, not people. The output contains no candidate data, no recruiter names or emails, and no descriptions — just the posting's public metadata and links.

ATS New Postings API

There is no single cross-ATS "job postings API" product; each platform runs its own public board API for embedding postings on customer career pages — Greenhouse's Board API (boards-api.greenhouse.io), Lever's Postings API (api.lever.co), and Ashby's public job-board API (api.ashbyhq.com). This Actor normalizes all three into one record shape, one filter set and one dedupe state, so a schedule can watch companies across platforms without three separate integrations. No API key, account or login is involved on any of the three.

Alternatives

Single-platform ATS scrapers exist for each of these platforms, and generic job-board scrapers cover individual boards one at a time — typically as one-off snapshots, priced per run or per page, with a different output shape per tool. This Actor is the monitor-shaped option: all three platforms in one feed, delivered on a schedule, only-new dedupe against your own state store, and a flat per-posting price with no start fee.

Legal and data

Sources. All records come from the public job-board APIs that Greenhouse, Lever and Ashby themselves operate so that companies can embed their public postings on career pages and partner sites: boards-api.greenhouse.io, api.lever.co and api.ashbyhq.com. The Actor uses these feeds exactly as offered — unauthenticated, at a modest request rate, reading only publicly listed postings.

No personal data. Job postings are company-published role descriptions. They contain no candidate or applicant data, and this Actor additionally strips the payload down to a fixed field whitelist (title, location, department, dates, links) — job description text and any other payload fields are never copied into the output.

Your responsibilities. Postings remain each company's content. Respect each board owner's terms and the platforms' terms of use, use the data for legitimate recruiting, lead-generation and market-research purposes, and do not use this Actor to spam applicants or employers.

Limitations

• Greenhouse dates use the first-published date. Companies often bulk-edit every open Greenhouse posting at once, which resets updated_at. This Actor filters on first_published, so a bulk edit never makes old jobs look new or bills you for them. The last-edit time is kept in updatedAt for reference.
• Greenhouse has no department field in its public board payload, so the departments filter excludes Greenhouse postings, and Greenhouse records omit department/team.
• First only-new run = baseline. With a fresh state store, the first run delivers the full in-window set (see Scheduling). If you want to start from zero instead, run once with a tiny window (e.g. postedWithinDays: 1) to seed the store.
• Boards are fetched in full. Each run downloads each configured board's current postings and filters locally; that is what makes only-new dedupe and the filters exact, and it means very large boards (thousands of postings) take proportionally longer — the run stops gracefully at the platform timeout with partial results and a summary, never a crash.
• Unlisted/draft postings are not visible. The public APIs return published postings only, which is precisely the public signal this Actor is for.

Development

python3 -m venv .venv && .venv/bin/pip install -r requirements.txt pytest
.venv/bin/python -m pytest tests/ -q

Tests are network-free: trimmed real payloads from the three platforms (Greenhouse/airbnb, Lever/leverdemo, Ashby/Ramp), whitelist assertions that no unlisted field ever reaches a record, filter/date/dedupe coverage, bad-input soft-fail coverage, and mocked-transport fetch tests.