Greenhouse API Review: Developer Deep Dive [2026]

The question behind every ATS API integration is whether the surface goes deep enough to justify the dependency, or whether you will hit a wall three sprints in and wish you had evaluated more carefully upfront.

Greenhouse maintains not one API but eight distinct APIs, each scoped to a specific integration pattern: data access, job board publishing, candidate ingestion, assessment scoring, onboarding, audit logging, and two webhook channels.

The developer docs are public, the documentation source is open on GitHub, and the endpoint permissions are granular enough that an admin can toggle access per endpoint per API key. For a hiring platform serving 7,500+ companies, that is a mature developer surface.

But breadth and depth are different questions.

Greenhouse's APIs are recruiting APIs. They read and write hiring data: candidates, applications, jobs, scorecards, offers, and onboarding records. If your build needs programmatic access to an ATS, the surface covers the full hiring lifecycle with real depth.

But if your integration needs B2B intelligence alongside hiring data (contact enrichment, firmographics, org charts, technographics, or buyer intent signals to inform sourcing and recruiting decisions), that is a different layer of the stack entirely.

This is where ZoomInfo enters the picture: a GTM platform whose Enterprise API is a REST suite covering search, enrichment, AI intelligence, and audience management across 500M contacts and 100M companies, with OAuth 2.0 authentication and an MCP server for AI-agent workflows.

Where Greenhouse's API manages the hiring process, ZoomInfo's API provides the candidate and company intelligence that feeds it.

This review covers the Greenhouse API surface in full technical depth first, then reviews ZoomInfo's API as the intelligence layer that picks up where ATS data stops.

Greenhouse API at a Glance

Greenhouse API: What Works Well & What to Plan Around

Greenhouse API: Authentication & Getting Started

Greenhouse uses different authentication methods across its APIs, each matched to the integration pattern the API serves.

Harvest API (HTTP Basic Auth): The primary data-access API uses HTTP Basic Authentication over HTTPS. The API key serves as the username; the password field stays blank. You Base64-encode <api_key>: and pass it in the Authorization: Basic <encoded> header. All requests must use HTTPS; HTTP returns a 403.

You provision API keys in the Greenhouse UI under Configure > Dev Center > API Credential Management. This requires the "Can manage ALL organization's API Credentials" developer permission. Permissions are endpoint-scoped: administrators can grant or revoke access per endpoint, giving fine-grained control over what each integration reads or writes.

A basic authenticated request looks like this:

curl "https://harvest.greenhouse.io/v1/candidates" \

-H "Authorization: Basic $(echo -n 'YOUR_API_KEY:' | base64)"

Candidate Ingestion API (OAuth 2.0 or Basic Auth): The Ingestion API supports two authentication paths. For partner-to-user flows, OAuth 2.0 is preferred: partners register an application with Greenhouse, receive a consumer key and secret, and include the resulting bearer token as Authorization: Bearer <access_token>.

OAuth scopes include candidates.create, candidates.view, and jobs.view. For system-to-system submissions, Basic Auth is used alongside a mandatory On-Behalf-Of: <email> header.

Source: Greenhouse

Audit Log API (JWT Bearer Auth): The Audit Log API uses a two-step process: a Harvest API key calls POST https://harvest.greenhouse.io/auth/jwt_access_token, which returns a JWT valid for 24 hours. That token authenticates all subsequent audit log requests.

Webhooks (HMAC Signature Verification): Recruiting Webhooks include a Signature header containing a SHA-256 HMAC digest computed from the webhook's secret key and the full JSON body. Webhooks also support optional HTTP Basic Auth credentials and custom headers for delivery to secured endpoints.

One constraint worth noting early: there is no self-serve developer sandbox on Core or Plus plans. The developer sandbox and sync feature is available only on the Pro tier.

Greenhouse API: Core Endpoints & Capabilities

The Harvest API is the primary surface for reading and writing recruiting data. It covers the full lifecycle of a hiring process, from job creation through offer management.

General conventions: snake_case attribute names, ISO-8601 timestamps, null for missing values, JSON responses, and a policy of additive-only changes (properties are never removed or renamed).

Candidates & Applications

The candidate and application resources form the core of most integrations.

Candidates: List, retrieve, create, edit, merge, and anonymize candidate records. You can add notes, attachments, education entries, and employment history to any candidate. A prospect-to-candidate conversion endpoint handles the transition from sourced prospect to active applicant without creating a duplicate record.

Applications: List, retrieve, advance (move to the next stage), move between stages within a job or to a different job, reject, unreject, and hire. You can add attachments per application.

The advance and move operations are useful for automated pipeline workflows: a scoring service can advance qualified candidates automatically, or a scheduling integration can move candidates to an interview stage once a slot is confirmed.

What you would build with this: a CRM-to-ATS sync that creates candidates when a sales-qualified lead becomes a recruiting prospect, or a screening service that advances or rejects candidates based on assessment scores.

Jobs, Job Posts & Openings

Jobs: Create, update, and retrieve full job records including hiring teams, custom fields, and associated openings. The hiring team endpoint returns the full panel (recruiters, coordinators, hiring managers) for a given job.

Job Posts: Manage the public-facing representation of a job, including status, custom location fields, and content. The Job Board API provides a separate, read-only public surface for building custom career pages and department-level job listings without authentication.

Openings: Create, edit, and destroy openings within a job. Openings represent individual headcount slots, which matters for organizations tracking filled versus approved positions.

Interviews & Scorecards

Scheduled Interviews: Full CRUD on interview schedules, letting calendar integrations create and manage interview slots programmatically.

Scorecards: Retrieve scorecards per application, giving downstream systems access to interviewer evaluations. The Assessment API extends this: assessment platforms can push scorecard data back into Greenhouse in the same format as human interviewers, so automated assessment results sit alongside manual evaluations in the candidate profile.

Source: Greenhouse

Offers & Approvals

Offers: List, retrieve the current offer for an application, and update offer details. The offer endpoints matter for HRIS integrations that need to pull compensation data and start dates once a company extends an offer.

Approvals: Retrieve approval flows, request approvals, replace approvers, and manage pending approvals per user. Approval workflows in Greenhouse are configurable and multi-stage, so the API surface handles the full approval chain.

Users, Custom Fields & Reference Data

Users: Create, enable, and disable user accounts. Change permission levels and manage both current and future job-level permissions programmatically.

Custom Fields: Full CRUD on custom field definitions and their options, letting integrations extend the Greenhouse data model without manual configuration.

Reference data: Departments, offices, tags, sources, tracking links, email templates, rejection reasons, and demographic data (EEOC question sets and answers) are all accessible for reporting and compliance integrations.

Audit Log API

The Audit Log API exposes a single GET /events endpoint returning a 30-day rolling log of access and configuration events. You can filter by performer IDs, performer types, performer IP addresses, event types, event target IDs, event target types, request IDs, and request types.

This is the endpoint compliance teams care about most, and it is restricted to the Pro plan.

Greenhouse API: Webhooks & Events

Greenhouse's Recruiting Webhooks push event notifications covering the full hiring lifecycle.

Webhook configuration requires a name, an HTTPS endpoint URL, and a secret key for HMAC signature generation. On save, Greenhouse pings the endpoint; if the ping fails, the webhook is created in a disabled state.

The event catalogue spans four categories:

Application events: application created, deleted, updated; offer created, approved, updated, deleted; prospect created.

Candidate events: candidate deleted, hired, merged, stage change, unhired, rejected, unrejected, updated, anonymized.

Interview events: interview deleted, scorecard deleted.

Job events: job created, deleted, updated, approved; job post created, updated, deleted; job stage deleted.

Organization events: department deleted, office deleted.

Each delivery includes a Greenhouse-Event-ID header for idempotency tracking. Payloads share common attributes including application.id, application.status (one of rejected, hired, active), application.candidate.id, and a custom_fields hash map.

Retry policy: On delivery failure, Greenhouse retries up to 7 times over about 15 hours with exponential backoff: 1 min, 15 min, 60 min, 120 min, 240 min, 480 min. The published retry schedule is explicit enough to design your receiver around.

Onboarding webhooks are a separate channel, currently in beta. They fire employee:updated events with HMAC-SHA256 authentication and a 7-attempt retry policy.

What you would build with this: a real-time integration that pushes candidate-hired events to your HRIS, triggers onboarding workflows on offer acceptance, syncs stage-change events to a BI dashboard, or alerts a Slack channel when someone submits a scorecard.

Greenhouse API: SDKs, Docs & Rate Limits

SDKs & Libraries

Greenhouse publishes official libraries under the grnhse GitHub organization:

• Ruby: greenhouse_io (MIT license; last updated January 2026)

• PHP: greenhouse-tools-php, providing four service classes: Job Board Service, Job API Service, Application Service, and Harvest Service

• Ruby (OAuth): omniauth-greenhouse for Greenhouse OAuth flows (MIT license, last updated January 2026)

Two languages is narrow coverage. There are no official Node.js, Python, Java, or Go SDKs. Third-party community libraries exist but Greenhouse does not maintain them. For most modern integration stacks (Node.js and Python in particular), you are making direct HTTP calls and owning the auth, retry, and error-handling layer yourself.

Documentation & Developer Experience

The developer portal at developers.greenhouse.io uses a two-column layout: narrative documentation on the left, code examples (cURL and Ruby) switchable via tabs on the right. Every endpoint includes request/response schemas and example payloads.

Three things stand out about the developer experience:

• The documentation is open source on GitHub, so customers and partners can file issues or submit pull requests. An active issues tracker on the docs repo shows community engagement.

• Greenhouse maintains a dated changelog per API (the Harvest changelog logs entries with specific dates), giving integrators a way to track surface changes.

• API Credential Management is self-serve within the Greenhouse UI, with per-endpoint permission toggling on API keys. This granularity is uncommon and useful for organizations running multiple integrations with different access needs.

What the documentation does not include: no interactive API explorer (no Swagger UI, no OpenAPI spec download), no Postman collection, and no sandbox environment outside the Pro plan's developer sandbox and sync feature.

Without an interactive explorer, you confirm response shapes by reading docs and making test calls, not by clicking through a try-it interface.

A status page at status.greenhouse.io provides service health monitoring.

MCP integration: Greenhouse launched an MCP server in June 2026, giving hiring teams a governed way to connect AI agents (Claude, ChatGPT, Gemini) to Greenhouse data. The MCP was developed with design partners including StubHub and Komodo Health.

Rate Limits & Constraints

Harvest API: Requests are limited to the value in the X-RateLimit-Limit response header, per 10-second window. The documented default is 50 requests per 10 seconds. On breach, the API returns HTTP 429 with an X-RateLimit-Reset timestamp and a Retry-After header. Remaining capacity is tracked via X-RateLimit-Remaining.

Audit Log API: Standard requests are limited to 50 per 10 seconds. Paginated requests carry a stricter sub-limit of 3 requests per 30 seconds.

Pagination: Collection endpoints use Link header-based pagination (RFC-5988) with next, prev, and last relations. The Audit Log API uses cursor-based pagination with pit_id and next_search_after values; page size is set via a Size header (minimum 100, maximum 500 results per page).

The 50 req/10s default is a modest ceiling. For integrations syncing large candidate databases or running frequent polling loops, you will need to respect the rate headers carefully. If your Order Form specifies different limits, those override the default, and exceeding those limits may result in additional fees.

Data retention detail: Signed URLs for document attachments on AWS S3 are valid for 7 days (Harvest API) or 30 days (Audit Log API) and should be downloaded promptly.

Greenhouse API Pricing & Access Costs

Greenhouse bundles API access into its subscription plans rather than charging per call. You provision API keys through the Dev Center, available across Core, Plus, and Pro tiers.

However, certain API surfaces and developer tools are tier-gated:

• Core: Harvest API access, Job Board API, Candidate Ingestion API, Assessment API, and Recruiting Webhooks.

• Plus: Everything in Core. Fraud detection and CLEAR ID verification APIs become available.

• Pro: Everything in Plus, plus the Audit Log API, developer sandbox and sync, and enterprise-level data configuration.

All three tiers use custom pricing with no public price list. The cost depends on plan tier, hiring volume, organizational complexity, and required features. Subscription fees are based on employee headcount, including all employees of affiliates.

Two cost details to plan around:

• API overage fees: The Master Subscription Agreement states that usage beyond API limits specified in the Order Form may result in additional fees at the rates stated therein. Confirm your API limits and overage terms during contract negotiation.

• Professional services: Data migration, implementation, and custom development are billed separately under SOWs. Data export on termination is free via API self-export, but requesting a Greenhouse-produced export file is subject to Greenhouse's then-current data migration rates.

For a developer sizing costs: the API itself carries no per-call charges at standard usage. The real cost is the Greenhouse subscription tier that determines which APIs, features, and developer tools (sandbox, audit log) you can access.

Where the Greenhouse API Falls Short

These are the practical limits a developer should plan around. Several are scope decisions that reflect what Greenhouse is (an ATS) and what it is not.

Recruiting data only, no B2B intelligence. The API reads and writes hiring data: candidates, applications, jobs, scorecards, offers. There are no endpoints for contact enrichment, firmographics, technographics, org charts, buyer intent, or employment history beyond what a candidate submits.

If your integration needs to enrich candidate records with verified business emails, direct-dial phone numbers, or company intelligence, you need a second API.

SDK coverage is narrow. Official SDKs exist for Ruby and PHP only. Node.js, Python, Java, and Go integrations require direct HTTP calls with no maintained client library to handle auth, pagination, retry, and rate-limit backoff. For teams building in JavaScript or Python (the two most common integration languages), this adds real engineering overhead.

Rate limits are modest for high-volume syncs. The 50 req/10s default on the Harvest API (5 requests per second effective) works for event-driven integrations but constrains bulk data sync operations. A nightly job syncing 50,000 candidate records, with pagination and related resource fetches, will spend meaningful time waiting on rate-limit windows.

No interactive API explorer or OpenAPI spec. The documentation is clear and well-structured, but there is no Swagger UI, no OpenAPI spec download, and no Postman collection. Developers confirm response shapes by reading docs and making test calls, not by exploring interactively.

Audit Log API is Pro-only. The 30-day rolling access and configuration event log is restricted to the highest subscription tier. Organizations on Core or Plus that need programmatic audit trails for compliance (SOC 2 evidence collection, for example) cannot access this API.

Developer sandbox requires Pro. The developer sandbox and sync feature, which provides a safe environment for testing integrations without touching production data, is available only on the Pro plan. Core and Plus customers test against their live Greenhouse instance.

Harvest API v1/v2 sunset is imminent. The legacy v1/v2 Harvest API is deprecated with removal set for August 31, 2026. Integrations built against the legacy surface must migrate to v3 at harvestdocs.greenhouse.io before that date. The migration is not optional; it is a deadline.

No enrichment, no intelligence, no signals. This is the gap that matters most for developers building recruiting pipelines that go beyond tracking applicants.

Greenhouse can tell you that a candidate applied, what stage they are in, and what their scorecard says. It cannot tell you what company that candidate works for now, what technology stack that company uses, whether the company is hiring or downsizing, or whether the candidate's current employer is showing intent signals relevant to your recruiting strategy.

ZoomInfo API: The Intelligence Layer Greenhouse Does Not Cover

Greenhouse's API manages the hiring process.

ZoomInfo's API provides the candidate and company intelligence that informs it: who these people are, where they work, what those companies look like, and which accounts show signals that matter to a recruiting team. That intelligence flows from ZoomInfo's GTM Context Graph, which processes 1.5B+ data points daily by fusing ZoomInfo's B2B data with your first-party data.

The two APIs sit at different layers. A developer building a recruiting data pipeline would use Greenhouse's API to manage the candidate lifecycle and ZoomInfo's API to enrich, research, and prioritize the contacts and companies flowing through it.

What the API Covers

ZoomInfo's Enterprise API is a REST suite served from https://api.zoominfo.com/gtm, organized into four surface areas documented in the interactive API reference:

Data API (Search & Enrich): Search endpoints cover Contacts, Companies, Intent, News, and Scoops, returning matched records without consuming credits. Enrich endpoints unlock the full payload: business emails, direct dials, employment history, corporate hierarchy, org charts, technographics, and hashtag signals (up to 25 records per call).

The underlying dataset spans 500M contacts and 100M companies, 135M+ verified phone numbers, and 200M+ verified business email addresses. Search is free; enrichment consumes one credit per new record within a rolling 12-month window.

Source: ZoomInfo

AI Intelligence API: Account Summary returns structured account intelligence with a free-form Q&A endpoint. Find Similar Companies performs lookalike expansion from a seed account. Contact Recommendations returns AI-ranked buying-committee suggestions by motion (prospecting, deal acceleration, renewals).

What you would build with this in a recruiting context: enrich candidate records flowing through Greenhouse with verified contact data and employment history, research target companies for executive recruiting by pulling org charts and hiring signals, or prioritize sourcing efforts by identifying companies showing growth signals (new funding, executive hires, technology adoption) that indicate near-term hiring activity.

Authentication & Access

ZoomInfo uses OAuth 2.0 with PKCE via Okta, supporting three flows: Authorization Code with PKCE (web applications), Client Credentials (server-to-server), and Refresh Token.

Access tokens are 24-hour Bearer tokens with rotating refresh tokens. Teams register applications through the ZoomInfo Developer Portal, where they generate credentials, define scopes, and test endpoints.

This is a different authentication model from Greenhouse's static API keys. OAuth 2.0 supports delegated access, credential rotation, and scoped permissions, making it the stronger choice for multi-tenant integrations and enterprise security requirements.

Rate Limits, Credits & Developer Experience

Rate limits are published by tier: Builder (5 req/sec), Standard (25 req/sec), and Scaling (35 req/sec), with per-hour and per-day sliding-window limits enforced simultaneously. Every response includes quota headers with remaining capacity, and 429 responses include a Retry-After header with exact backoff timing.

Credits follow a rolling 12-month window: enriching a record for the first time consumes one credit; re-enriching the same record within the year is free. Search and lookup operations are free and do not consume credits.

For developers building AI agents, ZoomInfo's MCP server at https://mcp.zoominfo.com/mcp exposes search, enrich, and account research as native tools for MCP-compatible assistants, currently supporting Claude and ChatGPT.

Source: ZoomInfo

Documentation lives at docs.zoominfo.com with an interactive API reference, OAuth recipes in five languages, and an llms.txt index for AI development tools. ZoomInfo does not publish official SDKs, so both platforms require direct HTTP integration. Pricing follows a consumption-based model and is custom-quoted; ZoomInfo has added API access to all relevant plans.

BDO Canada reported an 87% reduction in time spent updating internal data dashboards using the ZoomInfo API, with one analyst describing the integration as plug-and-play across any process. (ZoomInfo)

Final Verdict

Greenhouse's API surface is well-documented and deep enough to support the full hiring lifecycle programmatically: candidates, applications, jobs, interviews, scorecards, offers, onboarding, and audit logging across eight scoped APIs with two webhook channels.

The open-source documentation, per-endpoint permission granularity, and explicit retry policies give developers the transparency needed to build with confidence. Its limits are limits of scope, not quality.

Choose the Greenhouse API if your integration is hiring-first: syncing candidate data to an HRIS, building a custom career page, pushing assessment scores into the ATS, automating stage transitions based on external signals, or feeding hiring analytics into a BI tool.

The eight-API architecture means you pick only the surfaces your build needs, and the webhook event catalogue covers the lifecycle events that drive most real-time integrations.

Choose the ZoomInfo API if your build needs the intelligence layer upstream of hiring: enriching candidate records with verified contact data and employment history, researching target companies for executive sourcing, identifying accounts showing hiring signals, or building AI-agent workflows that combine recruiting data with B2B intelligence.

The search-then-enrich pattern (search is free, enrich consumes credits) and the AI intelligence endpoints cover the data and reasoning that an ATS API does not. Explore the ZoomInfo Enterprise API or start with the developer docs to see the endpoint surface directly.

A developer who needs neither API should consider that Greenhouse's API does not cover B2B data intelligence, and ZoomInfo's API does not manage hiring workflows. If your pipeline requires both, the two are complementary layers, not competing surfaces.

FAQ

Is the Greenhouse API free?

API access is included in all Greenhouse subscription tiers (Core, Plus, and Pro) with no separate per-call charges at standard usage levels.

All tiers use custom pricing with no public price list, and the Master Subscription Agreement states that usage exceeding the API limits in your Order Form may result in additional fees. The Audit Log API and developer sandbox are restricted to the Pro plan. There is no free trial or free tier for Greenhouse; the only entry point is requesting a demo.

Does Greenhouse have a GraphQL API?

Yes, but only for onboarding. The Greenhouse Onboarding API (GHO) uses GraphQL exclusively, supporting queries on employee profiles, departments, locations, teams, custom fields, pending hires, and signature requests.

The primary recruiting APIs (Harvest, Job Board, Ingestion, Assessment, Audit Log) are all REST. If you need GraphQL for recruiting data, you would need to wrap the REST APIs in your own GraphQL layer.

What is the Greenhouse API rate limit?

The Harvest API default is 50 requests per 10-second window, tracked via the X-RateLimit-Limit response header. On breach, the API returns HTTP 429 with X-RateLimit-Reset and Retry-After headers. The Audit Log API shares the same 50 req/10s limit for standard requests but imposes a stricter 3 requests per 30 seconds for paginated requests. Your Order Form may specify different limits.

Are there official Greenhouse SDKs?

Greenhouse publishes official wrappers for two languages: Ruby (greenhouse_io) and PHP (greenhouse-tools-php), both hosted on GitHub under the grnhse organization. A Ruby OmniAuth strategy for OAuth flows is also available. There are no official SDKs for Node.js, Python, Java, or Go. Community libraries exist but Greenhouse does not maintain them.

Does the Greenhouse API support webhooks?

Yes. Recruiting Webhooks cover application, candidate, interview, job, and organization events with HMAC-SHA256 signature verification, custom headers, and a published retry policy of up to 7 attempts over about 15 hours with exponential backoff.

Onboarding Webhooks are a separate channel currently in beta, firing employee-updated events with the same HMAC authentication and retry count. You configure webhooks per endpoint URL with a secret key, and Greenhouse pings the endpoint on creation to verify reachability.

What does ZoomInfo's API add to a Greenhouse build?

ZoomInfo's API adds the B2B data and intelligence layer that Greenhouse's API does not cover. Where Greenhouse manages candidates, applications, and hiring workflows, ZoomInfo provides verified contact data (500M contacts, 200M+ verified business emails, 135M+ verified phone numbers), company intelligence (firmographics, org charts, technographics across 100M companies), and AI-powered research (account summaries, lookalike expansion, contact recommendations).

For recruiting teams, this means enriching candidate records with verified employment data, researching target companies for executive searches, and identifying accounts showing growth or hiring signals. The two APIs use different authentication models (HTTP Basic Auth vs. OAuth 2.0) and different pricing structures (subscription-bundled vs. credit-based), so plan the integration layer to handle both.