Greenhouse API: Developer Guide, Rate Limits, v3 Migration 2026 - 100Hires

Greenhouse does not have one API. It has five, and Harvest API v1 and v2 shut down after August 31, 2026, per Greenhouse's own API overview.

This guide covers which Greenhouse API fits your use case, how authentication and rate limits actually work, and where integrations get difficult, with a source for every claim.

The guide closes with a documentation-based comparison against the 100Hires API for teams weighing a lighter alternative. If you maintain an older Greenhouse integration, the migration deadline alone is reason enough to read this now.

Key takeaways

• Five APIs, two self-serve: per Greenhouse's API overview, Harvest and Job Board are the ones customers start using on their own. Assessment and Ingestion are partner-oriented, and Onboarding needs a separate subscription
• Hard deadline: Harvest API v1 and v2 become unavailable after August 31, 2026. New builds and old integrations both need OAuth-based v3
• Key creation is restricted: it requires the "Can manage ALL organization's API Credentials" permission, and each key must be granted access to individual endpoints
• Webhook gaps exist: the published event list has no candidate-created or interview-scheduled events
• The 100Hires API is smaller but fully self-serve: an open OpenAPI spec, self-generated keys, and access included on every paid plan

Which Greenhouse API do you actually need

Greenhouse's own API overview lists five separate APIs. The most common mistake at this stage is choosing the wrong API, so start here.

Two details from that table deserve emphasis. The Job Board API is genuinely public: every GET endpoint works without credentials, and only the application-submission POST needs a Base64-encoded key. The reviewed docs publish no hard numeric rate limit for it.

The Assessment API sits at the other extreme. Integration starts by emailing partners@greenhouse.io with your endpoint URLs, and the customer's Account Manager enters the key manually. There is no self-serve setup screen.

One naming note: "Harvest API" is a Greenhouse brand name, not an industry term. Other vendors later adopted the phrase, which still confuses buyers. More on that in the FAQ.

How do you get a Greenhouse API key

For Harvest v1/v2, Job Board, and Ingestion keys, the path is the same. Plan the permission request first: key creation is tied to a specific grant.

1. Get the permission. Key creation requires the developer permission called "Can manage ALL organization's API Credentials", per Greenhouse's key-creation article. It can be granted to Basic-and-above users; if yours does not have it, plan for an admin request
2. Create the credential. Go to Configure, then Dev Center, then API Credential Management, and choose the API type. Harvest v3 skips this flow entirely and uses OAuth client credentials instead of a key
3. Grant per-endpoint permissions. Access is binary per endpoint. The Harvest docs put it bluntly: a key with access to an endpoint sees everything in it. There is no field-level or record-level scoping, so scope each key to the endpoints it genuinely needs
4. Store the key immediately. After you click "I have stored the API Key", Greenhouse never shows it again. A lost key means creating a new one, re-provisioning the integration, and revoking the original

Authentication for v1/v2 is Basic Auth with a twist that trips people up: the key goes in the username field and the password stays blank.

curl -s https://harvest.greenhouse.io/v1/candidates?per_page=10 \
  -u "YOUR_HARVEST_API_KEY:"

Site Admins can restrict each credential to trusted IP addresses and revoke or re-enable it at any time, per the credential-management article. These credential controls are good security practice to adopt from day one.

Everything above describes the classic flow. It now has an expiry date.

What changes in Harvest API v3, and the August 31 sunset deadline

Greenhouse's API overview states that Harvest v1 and v2 will be deprecated and unavailable after August 31, 2026. Existing custom integrations must move to v3 by that date.

This is not a version bump. It is a different architecture, and the v3 authentication docs spell out the biggest change: OAuth 2.0 replaces permanent API keys entirely.

Custom integrations use the Client Credentials flow. Partner integrations use the Authorization Code flow. Either way, tokens expire and get reissued, which beats a permanent password shared with every vendor.

curl -s -X POST https://auth.greenhouse.io/token \
  -u "CLIENT_ID:CLIENT_SECRET" \
  -d "grant_type=client_credentials" \
  -d "sub=GREENHOUSE_USER_ID"

Note the sub parameter. Every v3 token acts on behalf of a specific Greenhouse user, and that user's permissions limit what the token can do. The docs add a sharp edge: list endpoints require a Site Admin as the authorizing user.

Three more breaking changes matter for migration planning:

• Cursor pagination replaces page numbers. Per the v3 pagination docs, page size defaults to 100 with a maximum of 500, and the cursor must be the only query parameter on follow-up requests. Filters go on the first request or you get a 422
• Child resources are no longer embedded. The v3 design notes confirm candidates no longer include their applications inline. Code that read nested data must switch to separate filtered calls
• Date fields follow a new convention. Per the v3 standardizations doc, date-only fields end in _on and timestamps end in _at

There is a bridge for the transition: existing v1/v2 key holders can mint short-lived v3 tokens from a dedicated endpoint. That bridge disappears with v1/v2, so treat it as scaffolding, not a destination.

Consultants have started marketing v1/v2 migration help to companies running older integrations, as one HR-technology consultant's warning shows. Budget the migration before the deadline forces it.

What are the Greenhouse API rate limits

It depends on your integration, and the response headers are the source of truth.

For v1/v2, the Harvest docs show 50 requests per 10 seconds as an example X-RateLimit-Limit value. The returned header defines your actual limit, and unlisted vendors may face stricter caps.

Exceeding yours returns a 429 with Retry-After and X-RateLimit-Reset headers.

Harvest v3 uses a different model, documented in the v3 rate-limiting guide: a fixed 30-second window, with 75 shown as the example limit. Token issuance is throttled separately on a 60-second window. Greenhouse publishes no single universal v3 number.

Some endpoints carry their own sub-limits. The Audit Log API, for example, caps paginated requests at 3 per 30 seconds on top of its general limit.

Two operational notes for sync jobs. At the documented example rate of 50 requests per 10 seconds, a nightly export of a 10,000-candidate org at 500 records per page takes under a minute of request time.

Attachments are the trap instead: resume and document URLs are signed links that expire after 7 days, per the Harvest docs. Download files immediately rather than storing the URLs.

What do Greenhouse webhooks cover, and what is missing

For event-driven integrations, Greenhouse webhooks beat polling. Each webhook is configured individually in the UI with a name, an HTTPS endpoint, and a secret key used for HMAC-SHA256 payload signatures.

According to the webhook documentation, Greenhouse makes up to 7 delivery attempts over 15 hours when an endpoint fails.

The setup behavior needs attention, though. When you save a webhook, Greenhouse pings your endpoint, and a failed ping creates the webhook in a disabled state.

Disabled webhooks never re-enable themselves. If a deployment or firewall issue causes the ping to fail, someone has to notice and manually switch the webhook back on.

The bigger constraint is event coverage. The published event list includes application-created, candidate-hired, stage-change, and job events.

What it does not expose: a separate candidate-created event. Interview events are limited to deletion. No interview-scheduled, no note-created, no email-sent.

Integrations that need those signals fall back to polling Harvest, which means rate limits become relevant again. If you are designing event-driven recruiting automations from scratch, our guide to ATS webhooks covers the patterns that hold up.

A Deel setup walkthrough shows three separate offer webhooks configured one at a time, each with its own endpoint URL and secret pasted by hand. There is no bundled installation flow for that setup, so plan for manual configuration.

Where developers actually hit friction with the Greenhouse API

Complaints about ATS APIs are easy to find and hard to verify. This section separates three different things: documented constraints, open reports from developers, and mistakes on the integrator's side that will still cost you time.

Documented constraints

These come straight from Greenhouse's own documentation. Binary per-endpoint data access. One-time key reveal. Webhooks that stay disabled after a failed ping. The event-list gaps above. Signed attachment URLs that expire after 7 days.

Add tier gating: custom fields on the application object require Enterprise-level accounts per the Harvest docs, and Greenhouse's own pricing page lists the developer sandbox and audit log under its top Pro tier.

Greenhouse sets expectations for the engineering effort itself. Its requirements for API-based job import say plainly that you need middleware, a developer to maintain the adapter, and a mapping schema. That is a fair, first-party statement of what building on the API costs.

Open reports from developers

These are user reports, not confirmed defects, and they are worth reading before you commit to an architecture.

On Greenhouse's own docs repository, developers have filed open issues about List Users filters returning unexpected results, incomplete Assessment API error documentation, a missing auth header in an example, and the lack of a total-record count on list responses.

An unresolved Stack Overflow question reports pagination on the User Permissions endpoint failing to advance past the first page for a user with more than 100 records.

Consistency concerns come up among practicing engineers too. One developer publicly described API inconsistencies as something defensive design cannot fully absorb.

In the same spirit, a senior developer prototyping against the Job Board API lists data consistency as the thing to verify before committing engineering time.

The loudest signal is not a bug at all. It is unmet demand for reporting.

Through 2026, talent-ops people have publicly built custom dashboards, MCP servers as weekend projects, and a free Claude-to-Harvest connector that drew 611 reactions, mostly to get at numbers the native reports do not surface.

Some teams hire consultants for exactly this work.

Implementation pitfalls to avoid

These failures originate on the integrator's side, and they recur often enough to list.

• Parse the content field as HTML. The Job Board API documents job descriptions, including qualifications, as HTML inside content. One job-platform founder expected structured fields and released a parser that produced empty qualifications for six weeks without reporting errors. Test parsers against captured real responses
• Keep Harvest calls server-side. A classic Stack Overflow case shows browser JSONP silently dropping the Basic Auth header and producing a 401 that looks like a credentials problem
• Match the credential to the version. A recruiting-ops user's Postman failure traced to using a v3 credential against a v1 endpoint with Basic Auth. The API version and auth scheme must match
• Map custom fields deliberately in HRIS syncs. A Workday-to-Greenhouse thread describes new job requisitions retaining template values instead of synced ones, with suggested fixes involving report and integration-user configuration
• Budget for support-mediated activations. Some marketplace integrations, per vendor guides like Crosschq's setup doc and video walkthroughs from assessment vendors, must be activated by sending your API key to Greenhouse support and waiting for confirmation

What the Greenhouse API does well

The Greenhouse API performs well in several areas. The public Job Board API is the example developers cite when asking why other ATSes lack an open jobs endpoint.

Engineers who work across ATS platforms rate Greenhouse's APIs as easier to consume than those of legacy suite vendors, and self-reported G2 reviews by users in engineering roles describe the documentation as clear and the API as reliable.

The v3 security model is a real upgrade with scoped, expiring OAuth tokens, and credentials support IP restrictions as an added control.

Greenhouse's own Navan case study, vendor-published but concrete, reports over 1,000 hours saved through a custom Harvest integration. At least one talent director picked Greenhouse for its integration ecosystem.

Most of the friction comes from access gating, version migrations, and edge-case documentation, not from fundamental capability. So what does a lighter-weight alternative look like?

How does the 100Hires API compare to the Greenhouse API

100Hires is our product. This comparison is based on each vendor's published documentation, and we did not run independent performance tests. Both sources are dated July 16, 2026: the 100Hires OpenAPI spec and the Greenhouse docs linked throughout this guide.

The limitations, stated plainly: 100Hires has no partner marketplace comparable to Greenhouse's integration ecosystem, and it supports API keys, not OAuth flows.

Its default rate limit is far lower than Greenhouse's documented examples, and there is no separate developer sandbox product.

If you run enterprise-scale HRIS integrations with approval chains and audit requirements, Greenhouse's ecosystem is ahead, full stop.

100Hires requires fewer setup steps between signup and a successful API request: any verified account can generate a key in Settings, with no permission request and no partner onboarding. The API documentation covers the rest.

Our own sales and hiring team runs candidate assessment and pipeline audits through this exact API and the MCP server built on it.

The choice splits along team size and integration needs. Small technical teams that want to script their ATS without permission requests or partner onboarding will find fewer setup gates with 100Hires.

Large organizations that need the partner ecosystem, enterprise governance, and the broadest API surface should stay on Greenhouse and plan the v3 migration.

Start a free 14-day 100Hires trial, generate an API key in Settings once your company is verified, and test your first request against the live spec.

Frequently asked questions

Does Greenhouse have an API?

Yes, five, per Greenhouse's API overview: Harvest, Job Board, Assessment, Ingestion, and Onboarding. Most teams need Harvest. 100Hires, for contrast, exposes one REST API with a public OpenAPI spec.

How do I get a Greenhouse API key?

Get the "Can manage ALL organization's API Credentials" permission. Then open Configure, Dev Center, API Credential Management, create the key, and grant endpoint access. Save the key when it first appears. A verified 100Hires account generates its key from Settings.

What is a Harvest API?

Harvest API is Greenhouse's name for its main data API, not an industry standard. Greenhouse's CTO has described the name as a data-harvesting pun that later spread to other ATS products. 100Hires simply calls its interface the API.

Is the Greenhouse API free?

API access comes with a Greenhouse subscription, and Greenhouse publishes no prices. The developer sandbox and audit log sit in its top Pro tier. The 100Hires API is included on every paid plan, with plans from $49 per month billed annually.

When do Harvest API v1 and v2 stop working?

After August 31, 2026, per Greenhouse's API overview. Any integration still on v1/v2 must move to OAuth-based Harvest v3 before then. If a migration has you re-evaluating your stack, the 100Hires API can be tested directly against its live OpenAPI spec.