Automating Docusign workflows with Greenhouse using webhooks

For HR and People Ops teams, the gap between "candidate accepted" in Greenhouse and "employee starts day one" is a bottleneck built almost entirely of paperwork. Offer letter, NDA, IP assignment, benefits enrollment, equity grant - often a dozen documents per hire. This guide describes the architecture for firing those documents from a Greenhouse event, using Baton as the webhook relay and Docusign Workflow Builder as the document generator.

What you'll need #

• A paid Greenhouse Recruiting account with admin access to Configure → Dev Center.
• A Docusign account with IAM and Workflow Builder enabled, plus a Greenhouse Extension App configured in your Docusign tenant if you want data to flow back to the candidate record.
• A Baton account.

How Greenhouse webhooks fire #

Greenhouse's webhook system is called Web Hooks. You configure a hook to listen for specific events (candidate stage change, offer approved, job post opened, etc.). Greenhouse HTTP POSTs a JSON payload to the URL you provide, signed with HMAC-SHA256 using a secret you generate at creation time.

Events useful for agreement automation:

Step 1 - Add the automation in Baton #

In Baton's Flow Builder, click + Add Automation. Select Greenhouse as the source (once it's in the catalog). Pick the target Docusign Workflow Builder workflow from the dropdown - populated by Baton's Workflow Checker, which syncs every workflow your Docusign org has plus the parameter contract each one declares.

Baton generates a unique webhook URL:

https://app.iambaton.com/hook/b2e5c9d7f1a4

Enter the Greenhouse-generated secret in the Webhook Secret field. Baton uses it to verify the HMAC signature on every incoming request.

Step 2 - Configure the Greenhouse webhook #

In Greenhouse, go to Configure → Dev Center → Web Hooks → Create Web Hook.

• Name: Baton: offer approved
• When: Offer Approved
• Endpoint URL: paste the Baton URL
• Secret Key: use the same secret you entered in Baton

Save. Repeat for whichever other events you want to route - each one becomes its own Baton automation with its own URL and its own target Docusign workflow.

Step 3 - How Baton matches fields #

There is no drag-and-drop field mapping UI in Baton. The mapping comes from your Docusign Workflow Builder workflow: its start trigger declares named parameters, and Baton matches the Greenhouse webhook payload fields against those names at runtime.

For example, if your Docusign workflow's start trigger declares a parameter called candidateId and the Greenhouse payload contains:

{
  "payload": {
    "application": {
      "candidate": {
        "id": 4217832,
        "first_name": "Ada",
        "last_name": "Lovelace",
        "email_addresses": [{ "value": "ada@example.com" }]
      }
    }
  }
}

Baton matches whatever named fields in the payload align with the workflow's parameter contract. If you need a different layout, you adjust the Docusign workflow to expect different parameter names. No Baton-side configuration required.

Step 4 - Monitor and debug #

Every webhook becomes a Relay in Baton's Relay log. The 2-phase lifecycle is visible on each entry:

1. Webhook verification → Verified (HMAC check passed)
2. Maestro Trigger → Launched (Docusign workflow started, Instance ID recorded)

If the HMAC fails, the Relay is marked verification_failed and nothing fires to Docusign. If a Greenhouse candidate record lacks a field your Docusign workflow requires (e.g. the parameter startDate is expected but the payload doesn't have it), the Relay is marked validation_error so you can inspect the raw payload and decide whether to adjust the workflow's parameter contract or the Greenhouse event payload.

What happens when a candidate declines #

Baton triggers workflows. It does not void or cancel Docusign envelopes - those are handled inside the Docusign workflow run itself, or manually in the Docusign UI. If you want a candidate-rejected event to cancel outstanding envelopes, that logic lives in your Docusign workflow (as an Extension App step that checks candidate status before proceeding) or in a separate operational process.

Why this architecture #

HR teams often end up building this pipeline with Workato, Zapier, or custom Lambda functions. The issue is never any individual step - it's that nobody owns the failure modes. A job stalls because Greenhouse rate-limited an API call, and a new hire shows up on day one with no signed offer. Recruitment manager calls Legal. Legal calls IT. IT calls vendor support.

Baton's model collapses that visibility problem: every trigger is a row in the Relay log with a persistent Webhook ID, Relay ID, and Maestro Instance ID. Failures surface in the Notifications Inbox and route to Slack. If your Greenhouse webhook never fires a Docusign workflow, you see it in red in the Flow Builder.

See Baton's pricing or browse the full list of supported integrations. If Greenhouse support in Baton matters for your team, reach out - we're tracking interest to prioritize the next batch of Live integrations.