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 an Action in Baton's Action 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 Action 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 Action 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 Action log with a persistent Webhook ID, Action 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.

If Greenhouse support in Baton matters for your team, reach out - we're tracking interest to prioritize the next batch of Live integrations.