The work happens after "completed"

Most teams treat a finished signature as the end of the process. It's actually the start of a chain of busywork: update the CRM, kick off onboarding, file the PDF, notify finance, start the clock on a deliverable. Done by hand, that work is slow and easy to forget. Done with webhooks, it happens the instant the event fires — with no human in the loop.

A webhook is just an HTTP POST your server receives when something happens. Instead of you asking "is this signed yet?" on a timer, the signing platform tells you the moment it is.

Stop polling

Polling an API every few minutes to check envelope status is the wrong default. It's wasteful, it's slow (your average detection lag is half your polling interval), and it doesn't scale once you have hundreds of envelopes in flight. Webhooks invert the relationship: zero requests until something actually changes, then an immediate notification. If you're writing a cron job to check signing status, you almost certainly want a webhook instead.

The events worth subscribing to

Hosting Sign emits a webhook for each meaningful state change. The ones that drive most automations:

  1. envelope.sent — the envelope went out. Use it to log the send in your system of record.
  2. recipient.signed — one signer finished. Useful for progress tracking on multi-signer deals where you want to nudge the next party or update a dashboard.
  3. envelope.completed — everyone signed. This is the big one: trigger onboarding, provisioning, fulfillment, or filing here.
  4. envelope.declined — someone declined. Route this to a human immediately; a dead deal needs attention, not silence. (See designing for the unhappy path — the decline is the event most automations forget.)
  5. envelope.voided — the sender cancelled. Reconcile your records so a voided agreement doesn't sit in your pipeline as "pending."

Verify the signature — every time

Here's the part teams skip and regret: a webhook endpoint is a public URL, and anyone who finds it can POST fake events to it. If your automation provisions accounts or releases funds on envelope.completed, an unverified endpoint is a way for an attacker to fake completions.

Every Hosting Sign webhook payload is signed with HMAC-SHA-256 using a per-subscription secret. On receipt:

  1. Read the signature header off the request.
  2. Compute the HMAC-SHA-256 of the raw request body with your shared secret.
  3. Compare the two using a constant-time comparison.
  4. Reject anything that doesn't match — before you parse or act on the payload.

An unverified webhook endpoint that takes a privileged action is a remote-control button for anyone who guesses the URL. The HMAC check is not optional.

Compute the HMAC over the exact bytes you received, not over a re-serialized version of the parsed JSON — re-serializing can reorder keys or change whitespace and break the comparison.

Make your endpoint idempotent

Networks are unreliable, so any honest webhook system retries. That means your endpoint will occasionally receive the same event twice. If a duplicate envelope.completed provisions two accounts or sends two welcome emails, that's on the consumer, not the sender.

The fix is cheap: every event carries a unique ID. Record processed IDs and ignore repeats. Design every handler so that processing the same event twice has the same effect as processing it once.

Respond fast, work later

Return a 2xx quickly — acknowledge receipt, then do the slow work (PDF download, third-party API calls) asynchronously. If you run a ten-second API call before responding, you'll trip delivery timeouts and trigger needless retries. Acknowledge first, process second.

When delivery fails

Endpoints go down. Deploys happen mid-delivery. That's normal, and it shouldn't lose you data. Hosting Sign keeps a webhook delivery log that records every outbound attempt with its response code and attempt count, so you can see exactly which events reached you and which didn't. When an endpoint was down during a burst of completions, you can redeliver any failed event with one click once it's back — no manual reconstruction, no missed onboarding.

Webhooks vs. no-code

You don't always need to write a receiver. Hosting Sign's webhooks are Zapier-compatible, so non-engineers can wire "on envelope completed, create a row / send a Slack message / start an onboarding sequence" without touching code. Use Zapier for the long tail of internal glue; use a real endpoint when the action is privileged, high-volume, or needs the HMAC guarantee.

Where to start

Pick one event and one action. The highest-leverage first automation is almost always envelope.completed → "file the signed PDF and audit certificate in our system of record." It removes a manual step on every single agreement, and because the signed package already carries a court-ready audit trail, you're filing evidence, not just a document. Once that's solid, add the next event. Automation compounds — but only if each link is verified, idempotent, and fast.