Automating Docusign workflows with Dayforce using webhooks

Dayforce does not ship native HubSpot-style webhook subscriptions, so the way to trigger a Docusign IAM Workflow Builder workflow from a Dayforce event (new hire, termination, status change, pay-period close) is to push the event out of Dayforce as an outbound HTTP POST through Dayforce Integration Studio or the Event framework, land it on a webhook relay that verifies the signature and matches the payload to a Workflow Builder parameter set, then let Workflow Builder create the envelope. This article shows the architecture end-to-end and the gotchas that bite HR ops engineers wiring this for the first time.

Why Dayforce plus Docusign is awkward today #

Dayforce has a native Docusign eSignature for Dayforce listing on Dayforce Exchange that wires Docusign signing tasks into the Onboarding module. It is genuinely useful for new-hire packets, and Dayforce's own help portal documents how to configure e-signature functionality and manage Docusign templates inside Onboarding. That covers the most common signing job a Dayforce customer needs.

It stops being enough the moment your agreement workflow is more than a single template inside the onboarding wizard. Mid-cycle promotion letters, role-change addenda, expat assignment letters, multi-country DPA and W9 packets, termination releases, contractor conversion paperwork - those all live outside the Onboarding signing context. They need a workflow primitive that branches by country, fans out to multiple signers, waits for a manager to approve before sending, then writes the signed PDF somewhere durable. That is what Docusign IAM Workflow Builder is for, and the native Dayforce listing does not trigger Workflow Builder runs.

The second piece of awkwardness is the event side. Dayforce does not expose a self-serve webhook subscription page where you pick "new hire" and paste a URL. Stitchflow's API guide notes that Dayforce does not offer a native outbound webhook system for real-time event notifications. The outbound options that do exist - Integration Studio, the older Event framework, and scheduled exports - require an implementation pass, not a checkbox.

So the practical pattern is the same one we use for any platform that does not hand you a clean webhook UI: emit the event as an outbound HTTP POST from Integration Studio, relay it, and trigger Workflow Builder.

Which Dayforce events can fire outbound HTTP #

Dayforce's Integration Studio is the supported way to build event-driven outbound integrations. Per Dayforce's product page, Integration Studio gives access to "APIs and event-driven services" so integrations are workflow-driven instead of file-batch only. A practical walkthrough from Red Pill Labs confirms that outbound data can be pushed to external APIs as JSON, sourced from the Dayforce HCM Anywhere API and Event framework.

In practice you will design Integration Studio flows around these event sources:

• Employee hire / rehire - fires once a new employee record is committed. Useful for offer-letter addenda, equity grant agreements, and country-specific NDAs that sit outside the standard onboarding packet.
• Employee status change - role, location, manager, employment type. The trigger for promotion letters and internal transfer agreements.
• Termination - the trigger for separation agreements, release-of-claims, and equipment-return acknowledgements.
• Pay-period close or off-cycle pay event - useful for variable-comp letters and commission statements that require sign-off.
• Custom form submission - any Dayforce form (expense, leave, custom HR) that should kick off a signed acknowledgement.

What you should not assume: there is no public "subscribe via API" endpoint comparable to HubSpot's developer webhook app. Each event source has to be modelled inside Integration Studio (or built against the REST API with a polling worker) before the JSON ever leaves Dayforce. Budget for that implementation time up front.

The relay architecture: Dayforce to Baton to Workflow Builder #

The shape is the same one Baton uses for every source platform - a thin, opinionated relay between the source event and Workflow Builder:

Dayforce Integration Studio (event-driven outbound JSON)
        |
        v   HTTPS POST + HMAC header
Baton webhook relay
        |  - verifies signature
        |  - matches payload fields to Workflow Builder parameter names
        v
Docusign IAM Workflow Builder
        |  - branches, fans out, sets signers
        v
Docusign envelope(s) sent

A few things to understand about what each box does and does not do:

• The relay does not call Dayforce. There is no OAuth back to Dayforce, no stored Dayforce credentials, no polling. Dayforce pushes; the relay listens. That keeps the failure domain small and the credential blast radius minimal.
• The relay does not create the envelope. It triggers a Workflow Builder workflow. Workflow Builder is the thing that branches on country, picks the template, sets signer order, and creates the envelope. Treat Workflow Builder as the orchestrator and the relay as a typed front door.
• The relay is not a replacement for Docusign Connect. Connect is how Docusign tells your systems that an envelope changed state. The relay is how a source system tells Docusign to start a workflow. Different direction, different failure mode. You will usually want both.

Mapping employee and pay-period fields to Workflow Builder parameters #

The key design decision is the JSON shape Integration Studio emits. Workflow Builder matches incoming payload keys to workflow parameter names automatically - there is no field-mapping UI in the relay, no JSONPath, no drag-and-drop. So the contract is: the Integration Studio payload's top-level keys must match the parameter names you defined on the Workflow Builder workflow.

A sane payload for a new-hire signed-document workflow looks like this:

{
  "event_type": "employee.hired",
  "event_id": "df_evt_8a3f9c12",
  "employee_email": "jordan.lee@example.com",
  "employee_first_name": "Jordan",
  "employee_last_name": "Lee",
  "employee_xref": "EMP-10421",
  "country_code": "US",
  "legal_entity": "Acme US Inc",
  "manager_email": "rohan.patel@example.com",
  "start_date": "2026-06-01",
  "template_key": "offer_letter_us_v3"
}

Three things to notice:

1. event_id is your idempotency key. Make Integration Studio emit a deterministic value per Dayforce event so retries do not double-trigger Workflow Builder runs. If Dayforce retries the same event with the same event_id, the relay should short-circuit and return 200 without re-triggering. The same idempotency pattern shows up across every Baton integration; we cover the consumer side in why Docusign webhooks fail silently.
2. country_code is the branch key. Workflow Builder's conditional logic should fan out from one parameter the relay can guarantee. Modelling the country inside the payload, instead of inside the template_key, lets you change templates without redeploying the Dayforce Integration Studio package.
3. No PII you do not need. SSN, DOB, bank account, work authorization details - none of that belongs in the trigger payload. Workflow Builder pulls anything sensitive from Docusign-side data sources, not from the trigger.

Keep the payload narrow, named exactly to match Workflow Builder parameter names, and your "field mapping" problem disappears.

Securing the webhook endpoint with HMAC #

Outbound webhook security with Dayforce is implementation-defined - the receiver decides. The pattern Baton uses, and the pattern Docusign itself uses on Docusign Connect, is HMAC-SHA256 over the raw request body with a shared secret.

On the Dayforce side, Integration Studio will sign the outbound request: compute HMAC_SHA256(secret, raw_body), hex-encode it, and set it as a header (for example X-Baton-Signature). On the relay side, the listener recomputes the digest from the bytes it received and uses a constant-time compare.

Docusign's own HMAC verification guide for Connect and the step-by-step validation doc describe the same pattern from the other direction - worth reading because the relay will need to validate Docusign Connect on the way back out, not just Dayforce on the way in.

A minimal Python verifier on the relay:

import hmac, hashlib
 
def verify(raw_body: bytes, header_signature: str, secret: bytes) -> bool:
    expected = hmac.new(secret, raw_body, hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, header_signature)

Two failure modes that cost teams hours:

• Reparsing JSON before verifying. Always HMAC the raw bytes Dayforce sent, not a re-serialised dict. A single whitespace difference invalidates the digest.
• Secrets in URLs. Do not put the secret in a query string "for convenience." Proxies and access logs will leak it.

What is supported today versus on the roadmap #

To set expectations clearly:

• Supported today (general pattern): Dayforce Integration Studio can emit JSON to an external HTTPS endpoint on event triggers; a webhook relay can verify HMAC, idempotency-check, and call Workflow Builder to trigger a workflow run; Workflow Builder can branch, fan out, and create envelopes.
• On the roadmap for Baton: a turnkey Dayforce source-platform template in the Baton Command Center with a published payload shape, sample Integration Studio config, and observability on the Dayforce-to-relay leg. Today this build is bespoke per customer.
• Not in scope for Baton, period: OAuth into Dayforce, stored Dayforce credentials, polling Dayforce for events, or any bi-directional sync that writes data back into Dayforce. Write-backs to Dayforce belong in a Docusign App Center extension app, not in the relay.

If you need write-back of the signed PDF into the employee record, plan that as a separate workstream on the Docusign side. The Docusign App Center extension apps framework is where data write-back lives, and it runs on Workflow Builder completion events rather than on the trigger path.

Sending signed PDFs back to the employee record #

Once Workflow Builder finishes a run, you have two reasonable options for getting the signed PDF visible to HR ops inside Dayforce:

1. Push from Docusign to Dayforce via Integration Studio inbound. Configure a Docusign Connect listener that fires on envelope-completed events. The listener (or a Docusign App Center extension app) calls Dayforce's REST API to attach the signed PDF to the employee's document folder. This is the cleanest production pattern when Dayforce is your system of record for the HR file.
2. Keep documents in Docusign and link out from Dayforce. Store the signed envelope ID against the employee's external reference. From Dayforce, surface a link to the Docusign envelope. This is faster to build and avoids duplicating file storage.

Either way, the write-back is a separate flow from the trigger flow described above. Keeping them separate keeps the failure domains separate - a flaky Dayforce REST endpoint should not stop new agreements from being triggered, and a paused Workflow Builder workflow should not break document archival.

Next step #

If you are scoping a Dayforce-to-Docusign onboarding or termination flow right now, the fastest way to pressure-test the architecture is to talk to someone who has shipped the Integration Studio outbound side and the Workflow Builder side against the same relay. Start with the Baton resources hub for the integration recipes that are already live, then bring us the Dayforce specifics and we will help you wire it.