Greenhouse Harvest API v1/v2 Sunset and Your Docusign Flow

Greenhouse is removing Harvest API v1 and v2 on August 31, 2026, per Greenhouse's own API overview - any custom integration still calling those versions will stop working that day. If your Greenhouse-to-Docusign pipeline was built before a webhook-only relay existed, there is a real chance it quietly leans on Harvest v1/v2 somewhere, even though the trigger itself looks like a webhook.

What is changing in the Greenhouse Harvest API on August 31, 2026? #

Greenhouse Recruiting's Harvest API is the general-purpose REST API for reading and writing candidate, job, application, and offer data. Greenhouse confirms on its own developer docs that "the Harvest v1/v2 API is deprecated and will be removed on August 31, 2026," with everyone directed to Harvest v3.

The two versions are not a drop-in swap. Three things change at once:

• Authentication. Harvest v1/v2 uses HTTP Basic Auth with an API key as the username and a blank password. Harvest v3 requires OAuth 2.0, where you exchange client credentials for a short-lived bearer token (a JWT) at https://auth.greenhouse.io/token and send that token in the Authorization header on every request, according to Greenhouse's credential management docs and a developer walkthrough of the v3 flow.
• Pagination. Harvest v1/v2 pages results using RFC-5988 Link response headers. Harvest v3 switches to cursor-based pagination, so any code that parses a next URL out of a header needs to be rewritten rather than just repointed at a new host.
• User attribution on writes. Harvest v1/v2 impersonates a user via an On-Behalf-Of header. Harvest v3 instead attributes write actions to whichever Greenhouse user authorized the OAuth connection, per HackerRank's migration guide for the same cutover.

None of that is a config toggle. It is a genuine auth-and-pagination rewrite for anything still on v1/v2, and Greenhouse has already started letting admins export their current Harvest v1/v2 credentials from the Dev Center specifically so they can audit what is still in use before the deadline.

Sources: Greenhouse Harvest API overview, Greenhouse credential management docs, HackerRank's v3 migration guide.

Does the Harvest v1/v2 shutdown affect Greenhouse's recruiting webhooks? #

No. Greenhouse's recruiting webhooks (candidate hired, application created, offer approved, and the rest of the event catalog on Greenhouse's webhooks documentation) are a completely separate system from the Harvest API. Webhooks are push notifications signed with an HMAC SHA-256 signature over the request body; Harvest is a pull API you call with credentials. The August 31 deadline only removes Harvest v1 and v2. It does not touch webhook delivery, the HMAC signing scheme, or Greenhouse's documented retry behavior of up to seven delivery attempts over roughly 15 hours with exponential backoff before a webhook is marked failed.

That distinction is exactly why this deprecation is easy to miss. If your Docusign trigger is "just a webhook," it is genuinely unaffected. The risk is that most Greenhouse-to-Docusign integrations built before a dedicated relay existed are not just a webhook.

Where do Harvest API calls typically hide inside a Greenhouse-to-Docusign integration? #

Greenhouse's published webhook event catalog is deliberately narrow: Application created/updated/deleted, Offer created/approved/updated/deleted, Candidate hired/rejected/unrejected/unhired/merged/deleted, and candidate stage change. Notice what is missing. There is no standalone "interview scheduled" event and no plain "candidate created" event in that list - a gap independently confirmed by a third-party Greenhouse API guide, which flags that "the published event list has no candidate-created or interview-scheduled events."

When a team needed to trigger a Docusign offer letter or NDA off one of those missing moments, the practical workaround before a purpose-built relay existed was to catch a webhook that did fire (say, application created or candidate stage change) and then make a follow-up Harvest API call to fetch the interview schedule, pull a note, or look up a field the webhook payload didn't include. That follow-up call is where Harvest v1/v2 hides:

• A Lambda or serverless function that receives the webhook, then calls GET https://harvest.greenhouse.io/v1/candidates/{id} to enrich the payload before forwarding it to Docusign.
• A middleware layer that polls GET /v1/scheduled_interviews on a timer because there's no interview-scheduled webhook to react to.
• A script that looks up custom fields or attachments via Harvest because the webhook's payload doesn't carry them.
• Anything still authenticating with a stored API key and blank password, which is the Basic Auth pattern unique to v1/v2.

How do you audit your integration for Harvest v1/v2 calls before the cutoff? #

Work through this checklist for every Greenhouse-to-Docusign path you maintain:

1. Grep your codebase and middleware for the Harvest host and version. Search for harvest.greenhouse.io/v1 and /v2 literally, plus any environment variable named something like GREENHOUSE_API_KEY - that naming convention almost always means Basic Auth, which only exists on v1/v2.
2. Check for Basic Auth headers. Any outbound request that sets an Authorization: Basic header to a Greenhouse host is on the deprecated path, since Harvest v3 only accepts Bearer tokens.
3. Look for manual pagination code. Code that reads a Link response header and follows a rel="next" URL is written for v1/v2's RFC-5988 pagination and will not work against v3's cursor-based responses without a rewrite.
4. Export your current Harvest credentials from the Dev Center. Greenhouse's April 2026 release notes added the ability to export Harvest API v1/v2 credentials directly from the Dev Center for exactly this kind of audit - use it to see every key still provisioned and who owns it.
5. Trace what happens between "webhook received" and "Docusign workflow triggered." If there is any HTTP call to Greenhouse in that path beyond the initial webhook delivery, that call needs to be inventoried and migrated.
6. Watch rate-limit headers if you're already unsure how much Harvest traffic exists. Approved custom integrations are typically capped around 50 requests per 10 seconds, per Greenhouse's Harvest API rate-limit documentation; a pattern of throttling on your side is itself a signal that Harvest calls are load-bearing somewhere in the pipeline.

What changes when you migrate the same calls to Harvest v3? #

If the audit turns up real Harvest v1/v2 dependencies, the migration itself is mechanical but not optional:

# v1/v2 - Basic Auth, blank password
curl -u "GH_API_KEY:" \
  https://harvest.greenhouse.io/v1/candidates/57683957
 
# v3 - OAuth 2.0 bearer token
TOKEN=$(curl -s -X POST https://auth.greenhouse.io/token \
  -d "grant_type=client_credentials" \
  -d "client_id=$CLIENT_ID" \
  -d "client_secret=$CLIENT_SECRET" | jq -r .access_token)
 
curl -H "Authorization: Bearer $TOKEN" \
  https://harvest.greenhouse.io/v3/candidates/57683957

Budget time for three things beyond swapping the base URL: standing up the OAuth client-credentials exchange and token refresh, rewriting any pagination loop to follow cursor tokens instead of Link headers, and re-testing every write endpoint since v3 attributes actions to the OAuth-authorizing user rather than an impersonated On-Behalf-Of ID. None of this is difficult in isolation, but it is real engineering work with a hard external deadline, not a config change.

Why a webhook-only relay design was never exposed to this deprecation #

This is the design point worth understanding even if you're not migrating anything today. Baton is built as a webhook relay: Greenhouse fires a webhook, Baton verifies the signature, matches the payload fields straight to a Docusign Workflow Builder workflow's parameters, and triggers it. There is no polling loop, no stored Greenhouse API key, and no step that calls back into Harvest to enrich a payload - Baton holds credentials only for Docusign, never for source platforms.

That architecture is also why Baton never fills the "interview scheduled" or "note created" gap with a Harvest call the way a hand-built integration might. If a source platform's webhook catalog doesn't cover an event, the honest answer for a relay like Baton is that the event isn't available to trigger on yet, not a hidden API dependency that becomes a liability on a vendor's deprecation schedule. It's the same reasoning covered in more depth in what a webhook relay is and why Docusign needs one: the fewer credentialed calls an integration makes outside the webhook path, the fewer deprecation calendars it has to track.

There's a secondary benefit that shows up specifically during an audit like this one: because Baton never stores a Greenhouse API key in the first place, there is nothing to export from the Dev Center, nothing to rotate, and no Basic Auth credential sitting in an environment variable for a departed engineer to have half-remembered. The credential surface you're auditing for this deprecation is, for a webhook-only relay, empty by design rather than empty because someone happened to migrate it in time.

If you're running Baton's Greenhouse-to-Docusign integration today, the August 31 cutoff is not an action item for that pipeline specifically. It's still worth using this deadline as the trigger to audit anything else your team built around the same Greenhouse account.

What do you do if a Docusign trigger breaks after August 31? #

If a Docusign envelope stops generating, or generates with missing fields, right after the cutoff, work the problem in this order:

1. Confirm it's Harvest, not the webhook. Check whether Greenhouse's webhook delivery log shows the event firing successfully. If the webhook fired but the downstream envelope is wrong or missing, the break is almost certainly in a Harvest enrichment call, not in webhook delivery itself.
2. Check for 401s on the Greenhouse side. A Basic Auth request to a removed v1/v2 endpoint after August 31 will fail with an authentication error, not a 404 - it looks like a credentials problem even though the real cause is the version being gone.
3. Isolate the missing field. Compare what the webhook payload contains against what the broken Docusign field expects. The gap is your map of exactly which Harvest call needs migrating first.
4. Migrate that one call to Harvest v3 using the OAuth pattern above, re-test, and only then move to the next dependency your audit turned up.
5. Separate this from Docusign-side triggering failures. If the workflow itself never fires (as opposed to firing with bad data), that's a different failure domain - covered in why Docusign webhooks fail silently and how to catch them - and worth ruling out before you assume the cause is Harvest.

If you're weighing whether to patch the old integration or replace the polling layer entirely, that's the moment to look at a webhook-only relay instead of re-building the same Harvest dependency against v3. Wire your Greenhouse-to-Docusign flow up with Baton and the credential you're auditing today never becomes next year's deprecation deadline. For other platform-specific triggers and reliability patterns, browse the rest of the Baton resources library.