Get Greenhouse job postings via API

There are two ways to get Greenhouse job postings as structured data: read Greenhouse's own public feed for one company, or pull every Greenhouse board at once from a single normalized endpoint. The first is the right tool for a single employer's board. This guide covers both — what the vendor feed gives you, where cross-company aggregation requires something more, and how to get clean Greenhouse data without building the pipeline yourself.

The direct route

Greenhouse runs a clean, documented public Job Board API. A single GET to boards-api.greenhouse.io/v1/boards/{board_token}/jobs returns one company's published roles as JSON — no API key, no scraping — and ?content=true folds in the full descriptions, departments, and offices. The board token is the slug at the end of a company's Greenhouse careers URL. It is well-built and well-documented, and for one board it is all you need.

For one company's board at a time, that is the right tool, and you should use it. It is first-party, it is current, and it is free. If you are tracking a handful of companies you care about, a short script against their feeds will serve you well — there is no reason to reach for anything heavier.

Where it gets hard

The vendor feed answers one question well: what is open at this one company? The moment your question becomes what is open across Greenhouse as a whole, you are no longer reading a feed — you are running an aggregation pipeline, and that is a different job:

• Discovery. There is no master list of every Greenhouse board token. You have to find thousands of company identifiers and keep finding them as new employers onboard and others churn off.
• Polling at scale. Each board is a separate request. Refreshing thousands of them on a schedule — without hammering any one endpoint, while respecting rate limits and back-off — is real scheduling and infrastructure work.
• Normalization. Each feed reflects whatever the employer typed. Titles, locations, and seniority are inconsistent across companies, so "Sr. Eng II" and "Senior Software Engineer" need to resolve to the same normalized role and level before the data is comparable.
• Deduplication. Companies post the same role on multiple boards and re-post it over time. Without a stable dedup key you count one job several times.
• Silent disappearance. Postings vanish from a feed when they close, usually with no event. Knowing a role is gone — and when — means diffing every poll against the last.

None of this is exotic, but all of it is ongoing. It is the part that quietly turns a weekend script into a service someone has to own.

The aggregated alternative

We do that aggregation once, for every source, and expose the result as one endpoint. Right now that is 107,159 live Greenhouse postings from 4,977 companies, in one normalized shape. Filter to Greenhouse with ?source=greenhouse — the source filter is available on every plan, including the free tier:

curl -H "X-API-Key: YOUR_KEY" \
  "https://api.joblistingsapi.com/v1/jobs?source=greenhouse&limit=50"

The same call from Node, paging with the cursor:

// Node 20+ (global fetch, no dependencies)
// Every Greenhouse posting we track, in one normalized shape.
const res = await fetch(
  "https://api.joblistingsapi.com/v1/jobs?source=greenhouse&limit=100",
  { headers: { "X-API-Key": process.env.JLA_API_KEY } },
);
const { jobs, next_cursor } = await res.json();
console.log(jobs.length, "Greenhouse postings;", next_cursor ? "more" : "end");

And the pattern that replaces a polling scraper outright — backfill once, then sync only what changed with updated_since, also on every plan:

# Migration pattern for an existing Greenhouse scraper:
# stop crawling boards, sync deltas instead.

# 1. Backfill once — walk the cursor to the end.
GET https://api.joblistingsapi.com/v1/jobs?source=greenhouse&limit=100
  -> { "jobs": [...], "next_cursor": "eyJpZCI6..." }
GET https://api.joblistingsapi.com/v1/jobs?source=greenhouse&limit=100&cursor=eyJpZCI6...

# 2. Then poll only what changed since your last run.
GET https://api.joblistingsapi.com/v1/jobs?source=greenhouse&updated_since=2026-06-11T06:00:00Z

Migrating an existing scraper

If you already have a Greenhouse scraper in production, you do not rewrite it — you swap the source underneath it. Four steps:

1. Map your schema to ours. Line your existing columns up against the response fields in the docs — title, company, structured location, role_category, seniority, salary. Most scrapers already have these in some form; you are renaming, not redesigning.
2. Backfill. Pull the current Greenhouse set once with the cursor (or offset paging) until next_cursor is null, so your store starts complete.
3. Switch incremental syncs to updated_since. Replace your per-board polling loop with one delta call that returns only records changed since your last run.
4. Key your dedup on duplicate_cluster_id. Drop your home-grown fuzzy matching and trust the cluster ID — the same role across multiple boards already shares one.

FAQ

See the docs for the full response schema and filters, or the Greenhouse data page for live coverage counts.

Job Listings API is not affiliated with, endorsed by, or sponsored by Greenhouse. Greenhouse and other product names are trademarks of their respective owners.