How to obtain OAuth credentials for Greenhouse (Harvest V3)

Harvest V3 OAuth credentials for a partner integration are issued by Greenhouse, with a fixed set of scopes and redirect URIs that Greenhouse registers for your Client ID. Greenhouse's self-service Dev Center issues credentials only for an organization's own custom integrations (the Client Credentials grant, which is not what this connector uses) — a partner OAuth client for a multi-customer integration cannot be self-registered, so you request one from Greenhouse instead.

Who this guide is for. This is the application owner's side of Greenhouse credentialing — the team that ships an integration to its own customers. You apply to the Greenhouse Integration Partner Program, pass Greenhouse's Harvest V3 integration review, request one set of OAuth credentials, and enter them once in the Apideck Dashboard. From then on every customer organization authorizes against that one Client ID.

Greenhouse requires every integration to authorize with its own Greenhouse-issued credentials — there is no shared Apideck OAuth app to test on — so the OAuth flow can only run once Greenhouse has issued your Client ID and Client Secret. Plan for that lead time.

Consumers repeat none of this — their side is covered in How to Connect to Greenhouse.

Before you start, you'll need:

• A Greenhouse Integration Partner Program application (or an existing partnership). Greenhouse requires at least one mutual customer and an active website with a published Privacy Policy before an integration request can be submitted — both are required to apply, and Greenhouse does not accept every request.
• A Greenhouse organization to authorize against, with a Site Admin available to run the authorization: a partner sandbox, a Pro-tier customer sandbox, or a live customer organization.
• The ability to sign Greenhouse's Partnership Agreement and its API Agreement.
• Access to your integration's settings in the Apideck Dashboard.

1. Apply to the Greenhouse Integration Partner Program

Apply through the official Greenhouse Integration Partner application ("Apply now").

Greenhouse reviews applications on the first Monday of every month (the first Tuesday if that Monday is a holiday), and the Partnerships team follows up within 7 business days of that review. If the monthly cadence does not fit an urgent mutual-customer need, email partneronboarding@greenhouse.io with the justification to request an out-of-cycle review, and ask them for an expected timeline.

Once you sign the Greenhouse Partnership Agreement, Greenhouse grants access to the Partner Portal and to a sandbox environment for testing.

2. Complete Greenhouse's Harvest V3 integration review

Harvest V1 and V2 shut down on August 31, 2026, and Greenhouse requires your integration to be approved on V3 before your customer organizations can be moved onto it. Approval is what unlocks customer migration, so start it as soon as the partnership is signed.

Submit to partneronboarding@greenhouse.io:

• Updated support documentation for your integration, reflecting Harvest V3 behavior.
• A demo video of your integration running against Harvest V3.

Greenhouse also requires a new API Agreement to be signed as part of the V3 migration.

3. Request OAuth client credentials

With the partnership in place, request credentials from Greenhouse Partner Support at partner-support@greenhouse.io. Greenhouse asks for all of the following, so send them together (the Harvest partner OAuth guide is the vendor reference for this request):

Item	What to send
Integration name	The name customers will see on the Greenhouse authorization screen
Environment	testing (your own sandbox organizations only) or production (live customer organizations) — request both so you can test first
Required scopes	The eight harvest:* scopes in step 5
Redirect URI(s)	https://unify.apideck.com/vault/callback (see step 4)
Logo	A 128x128 logo file, shown to the user during authorization

Greenhouse issues a Client ID and a Client Secret out-of-band. testing and production credentials are issued separately — a testing Client ID authorizes only against sandbox organizations you control.

Adding or changing scopes on an issued Client ID also goes through Partner Support; there is no self-service UI for it, so send the complete scope list the first time.

4. Redirect URL

Register exactly this redirect URI with Greenhouse:

https://unify.apideck.com/vault/callback

It must match character for character — Greenhouse compares the redirect_uri sent at authorize time against the one registered for your Client ID, and a mismatch fails the authorization with error=invalid_request ('redirect_uri=…' is not configured for 'client_id=…'). Do not register a localhost or vendor callback for the Apideck connection; Apideck always sends the URL above.

For reference, the OAuth endpoints Apideck uses are Greenhouse's standard ones: https://auth.greenhouse.io/authorize for authorization and https://auth.greenhouse.io/token for the token exchange and refresh.

5. Scopes

Request all eight scopes below. Greenhouse provisions scopes as a fixed set on the Client ID — your app can only ever request what Greenhouse has provisioned, and the authorize call fails outright (error=invalid_scope, 'scope=…' is invalid for 'client_id=…') if a single requested scope is missing. There is no partial grant and no way to add a scope at authorize time, so a scope omitted here means going back to Greenhouse and re-authorizing every connection afterwards.

Scope	What it powers
harvest:candidates:list	Reading applicants
harvest:candidates:create	Creating applicants
harvest:candidates:update	Updating applicants
harvest:candidates:destroy	Deleting applicants
harvest:applications:create	Attaching a new applicant to jobs via application_ids on create
harvest:jobs:list	Reading jobs
harvest:job_posts:list	Reading job posts
harvest:job_posts:update	Updating and publishing job posts

harvest:applications:create was added after the initial V3 rollout. If a Client ID was provisioned before it existed, Greenhouse must add it to that client, and any connection authorized under the older scope set must be re-authorized in Vault before application_ids will work on applicant create.

6. Where the credentials go in Apideck

Greenhouse credentials are integration-level: you enter them once and every consumer connection uses them.

Open the Apideck Greenhouse connector settings in the Apideck Dashboard, then:

1. Fill in:

   Field	Value
   Client ID	The Client ID Greenhouse issued in step 3
   Client Secret	The matching Client Secret

2. Save the settings.

Consumers enter nothing — the connector defines no consumer-facing settings fields, so a consumer's only action is authorizing in Vault.

Greenhouse testing credentials authorize only sandbox organizations you control, so request production credentials before a live customer organization connects.

FAQ and troubleshooting

Can we use one Client ID for all customers? Yes — that is the model. One Greenhouse production Client ID and Client Secret, entered once at integration level, serves every customer organization; each customer simply authorizes its own Greenhouse organization against it.

Authorization fails with invalid_scope / "scope is invalid for client_id". One of the requested scopes is not provisioned on that Client ID. Compare the eight scopes in step 5 against what Greenhouse provisioned and ask Partner Support to add the missing one — this is not something the authorizing user's Greenhouse permissions can fix.

Authorization fails on the redirect URI. The registered URI does not match https://unify.apideck.com/vault/callback exactly. Check for a trailing slash, http:// instead of https://, or a stale URI from an earlier registration.

How do we rotate the Client Secret? Rotate it in Greenhouse (API Credential Management). The previous secret keeps working for up to one week — and can be deleted sooner once you no longer need it — which is the window to update the stored Client Secret in the Apideck Dashboard.

Testing credentials don't work against a live customer organization. Greenhouse scopes credentials to the environment they were issued for. Request a separate production Client ID and Client Secret before onboarding live customers.

A connection stops working after a quiet period. Greenhouse access tokens last 1 hour and the refresh token rotates on every refresh, idle-expiring after 24 hours. A connection unused for more than a day must be re-authorized from Vault — Apideck refreshes tokens automatically, but cannot refresh one whose refresh token has already expired.

Publishing a job post returns HTTP 403. This is not a scope or credentialing problem — it means the job board itself has not been published in Greenhouse. See the connector's Gotchas for the details.

Still stuck? Contact Apideck Support.