canonical: https://jentic.com/apis/greenhouse.io/greenhouse-greenhouse

# Greenhouse Harvest API

Jentic publishes the only available OpenAPI specification for Greenhouse Harvest API, keeping it validated and agent-ready. The Harvest API exposes the recruiting data model of a Greenhouse account - candidates, applications, jobs, departments, offices, scheduled interviews, and users - across 11 endpoints under harvest.greenhouse.io/v1. Authentication is HTTP basic, where the user portion is the Harvest API key and the password portion is left empty.

## For AI agents

Read Greenhouse candidates, applications, jobs, departments, offices, users, and scheduled interviews for ATS automation.

## Scope

Does not run payroll, store onboarding documents, or send interview invitations directly - use for reading recruiting data from Greenhouse only.

## Capabilities

- List and retrieve candidates from /candidates and `/candidates/{id}`
- Read applications associated with candidates and jobs via /applications
- Inspect open and archived jobs via /jobs
- List the recruiters and hiring managers via /users
- Retrieve the upcoming scheduled interviews via /scheduled_interviews
- Map the company's departments and offices via /departments and /offices

## Use cases

### ATS Data Sync into a Data Warehouse

People analytics teams pull Harvest data on a schedule into a data warehouse to build hiring funnel dashboards, time-to-hire reports, and diversity analyses. The /candidates, /applications, and /jobs endpoints together provide the canonical data set for funnel reporting.

Example prompt: Iterate /candidates with pagination over the last 30 days and load the records into a warehouse table

### Interview Scheduling Notifications

Recruiting coordinators run automation that polls /scheduled_interviews to detect newly booked interviews and post reminders into a chat tool with the candidate name, role, and panel. The endpoint returns interview times and panellist information needed to compose the message.

Example prompt: GET /scheduled_interviews for the next 24 hours and post each one to the recruiting chat channel

### Job and Department Reference Data Refresh

HRIS integrations refresh local mirrors of Greenhouse jobs, departments, and offices on a daily cadence so that downstream tools stay accurate. Each endpoint accepts pagination so that large catalogues can be retrieved in batches.

Example prompt: Page through /jobs, /departments, and /offices and replace the local reference tables with the latest Greenhouse data

### Agent-Driven Recruiting Assistant via Jentic

An AI recruiting assistant uses Jentic to discover the right Harvest endpoint when a recruiter asks 'who applied to the senior backend role?' or 'what interviews are tomorrow?'. Jentic injects the basic auth credentials from the vault and the agent works against structured Greenhouse data.

Example prompt: Search Jentic for 'list greenhouse candidates by job', load the schema, and execute /candidates filtered by job_id

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/candidates` | List candidates |
| GET | `/candidates/{id}` | Retrieve a candidate by id |
| GET | `/applications` | List applications |
| GET | `/jobs` | List jobs |
| GET | `/users` | List recruiter users |
| GET | `/scheduled_interviews` | List scheduled interviews |
| GET | `/departments` | List departments |
| GET | `/offices` | List offices |

## Key resources

- **candidates** — List and retrieve candidate records
- **applications** — Inspect applications connecting candidates and jobs
- **jobs** — List jobs and their statuses
- **users** — List recruiter and hiring manager users
- **scheduled_interviews** — Retrieve scheduled interviews on the calendar
- **departments** — List the company's departments configured in Greenhouse
- **offices** — List the company's offices configured in Greenhouse

## Why Jentic

- **Setup:** Wiring the Greenhouse Harvest API by hand means base64-encoding its basic-auth key, pointing at the harvest.greenhouse.io host, and mapping the candidate, application, job, and interview endpoints yourself. Through Jentic you install once, import the Greenhouse Harvest API from the API Directory, store the key once, and your agent calls it.
- **Permission scoping:** Greenhouse Harvest puts the candidate id in the URL path (`/candidates/{id}`), so a rule can pin your agent to one candidate: it can read that candidate's record and nothing else. You choose the operations it may call, and since this scope is read-only recruiting data, it stays within the reads you allow.
- **Credential handling:** Your Greenhouse Harvest key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'get a candidate's applications' or 'list open jobs', and Jentic returns the matching Greenhouse Harvest operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Greenhouse Harvest (extended)** — Same vendor, alternative slug exposing extended Harvest endpoints
- **Lever** — Modern ATS competitor to Greenhouse with a similar API surface
- **Workable** — ATS aimed at small and mid-market teams
- **Outlook Calendar** — Place scheduled interviews from Greenhouse onto a recruiter's calendar

## FAQ

### Why is there no official OpenAPI spec for Greenhouse Harvest API?

Greenhouse documents the Harvest API in their developer portal but does not publish a maintained OpenAPI 3 file for tooling. Jentic generates and maintains this spec so that AI agents and developers can call Greenhouse Harvest API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Greenhouse Harvest API use?

The Harvest API uses HTTP basic authentication. The username portion is the Harvest API key issued from the Greenhouse account settings, and the password portion is left empty. Through Jentic the API key is held in the encrypted vault and the basic auth header is built per call.

### Can I list every application associated with a candidate?

Yes. GET `/candidates/{id}` returns the candidate including their applications, and GET /applications can be filtered by candidate_id or job_id to retrieve the application list directly. Pagination uses the standard Harvest per_page and page query parameters.

### What are the rate limits for the Greenhouse Harvest API?

Greenhouse enforces a default Harvest rate limit of 50 requests per 10 seconds per API key, with burst behaviour. Exceeding the limit returns HTTP 429 with a Retry-After header. Jentic propagates the 429 so the agent can back off rather than hammer the limit.

### How do I retrieve upcoming scheduled interviews through Jentic?

Search Jentic for 'list greenhouse scheduled interviews', load the operation that maps to GET /scheduled_interviews, and execute it with optional starts_after and ends_before filters. The response lists interview times and panellists which the agent can render into a chat reminder.

### Does the API let me post a new candidate or schedule an interview?

The 11 endpoints in this spec are read-style operations. Greenhouse provides a separate Ingestion API for creating candidates from sourcing tools and the Harvest API itself supports additional write endpoints under specific permissions. Confirm with your Greenhouse account admin which scopes are enabled before relying on writes.

### Can I limit what my agent is allowed to do with the Greenhouse Harvest API?

Yes. Because you run Jentic One yourself, your own rules decide which Harvest operations and which stored key the agent may use, so you can allow only reads like GET /candidates, GET /applications, or GET /scheduled_interviews and block the rest. Since the candidate id sits in the URL path at `/candidates/{id}`, a rule can pin the agent to a single candidate, letting it read that record and nothing else. The scope you grant covers read-only recruiting data such as candidates, jobs, departments, offices, and users, so the agent stays within the endpoints you have permitted.