Greenhouse Jobs API.

The short answer

Greenhouse has two APIs and the confusion costs people days of integration work. The Job Board API is the public, read-only feed of any Greenhouse customer’s published jobs. The Harvest API is the private, authenticated API that gives full access to candidates, applications, and the recruiting workflow inside a specific customer’s account.

If you want to read job postings - across one company or many - you want the Job Board API. If you want to build a recruiting or ATS-integration product that reads candidates or writes data back, you want Harvest. Different surfaces, different auth, different problems.

The Job Board API at a glance

Fields you get

The Job Board API returns a stable but limited schema per posting. The common fields are id, title, updated_at, location (a single string),absolute_url (the apply link), and a structured departments and offices array. Some boards expose content (the job description, HTML-escaped) and metadata (custom fields the employer set), but both are optional and inconsistent across boards.

Notably not in the schema: salary, employment type (full-time / contract), remote flag, posted_at date (you get updated_at, not posted_at), expires_at date. Some employers include these in the content body or in custom metadata, but they aren’t first-class. If your workflow needs structured salary or remote data, you’ll be parsing free-text job descriptions or relying on a layer that does that for you.

Where it breaks at scale

The Job Board API is excellent for monitoring a small set of companies you care about. It breaks down for three things at scale.

Discovery. You need to know each company’s board_token in advance. There is no master list, no search endpoint, no way to enumerate every Greenhouse customer through the API. You collect tokens by scraping careers pages or by maintaining a manual list.

Coverage. Greenhouse is one of many ATSs. Lever, Ashby, Workday, SmartRecruiters, BambooHR, Workable, JazzHR and 20+ others all run their own ATSs with their own APIs and schemas. To cover the ATS landscape you have to integrate each one separately, normalize the schema, and handle each one’s rate-limit posture.

Freshness. The Job Board API is poll-only - no webhooks. You discover new postings by re-fetching every board on a schedule and diffing. For real-time triggers (a sales workflow that fires when a target account posts a role) polling is the wrong shape.

When to use it directly vs through a unified API

Use the Job Board API directly if you’re monitoring fewer than ~20 specific employers, you only care about Greenhouse, the polling cadence is loose (daily or slower), and you don’t need salary, employment type, or other structured fields beyond what the API publishes.

Use a unified jobs API like JobsPipe if you need cross-ATS coverage (Greenhouse + Lever + Ashby + Workday and so on), real-time webhooks on new postings, normalized salary and employment-type fields, or per-source attribution that lets you trace records back to the original ATS for debugging. We cover Greenhouse natively as part of a 30+ source surface, so you get the same Greenhouse data plus everything else behind one schema.

A first request, by hand

For a one-off look at any Greenhouse-hosted company’s jobs, no signup required:

# Replace {board_token} with the company's board id
curl https://boards-api.greenhouse.io/v1/boards/stripe/jobs

# Returns { "jobs": [ ... ] } with all currently-published roles

That endpoint is unauthenticated and returns whatever the company has chosen to publish. The same shape works for any Greenhouse-hosted board - just swap the token.