How to Automate Document Signing Workflows with eSignature Webhooks

Most eSignature platforms charge you a flat monthly fee whether you send one contract or a thousand. If you're building API-driven workflows, that pricing model punishes you for scaling. GoodSign flips that equation — at $1.50 per envelope with no subscription and no user limits, it's built for developers who want to automate document signing without burning budget on seat licenses nobody asked for.

This article covers how GoodSign's webhook events work, what you can trigger with them, and how to architect automation that actually holds up in production.

Understanding GoodSign's Webhook Event Model

Webhooks in eSignature workflows are simple in concept: when something happens to a document, your server gets notified. No polling, no manual checks, no brittle cron jobs. GoodSign fires events at each meaningful state change in a document's lifecycle.

The core events you'll work with:

• signer_opened — fires when a recipient opens the signing link
• signer_complete — fires when an individual signer finishes their signature
• document_complete — fires when all required signers have signed
• document_voided — fires when a document is cancelled or invalidated
• signer_declined — fires when a recipient explicitly declines to sign

Each payload includes the envelope ID, signer metadata, timestamps, and document status. That's enough context to drive meaningful downstream logic without extra API calls to fetch state.

Triggering CRMs and Internal Tools on Completion

The document_complete event is where most automation value lives. When a contract is fully signed, you want your systems to know immediately — not when someone remembers to update a deal stage.

A common pattern: listen for document_complete, extract the envelope metadata, and push an update to your CRM. In HubSpot or Salesforce, this means closing a deal, updating a contact property, or kicking off an onboarding sequence. The webhook payload gives you enough to match the envelope back to a deal record if you stored the envelope ID when you sent it.

For internal visibility, the same event hits a Slack webhook and posts a message to your #deals-closed channel. 65.3% of GoodSign documents are signed within 24 hours, so these notifications aren't theoretical — your team will see them regularly enough that the automation earns its keep fast.

Using signer_opened and signer_declined for Pipeline Intelligence

signer_opened is underused. Most developers wire up completion events and ignore the rest, but opened events give you something valuable: visibility into where a deal is stalling.

If a proposal is opened but signer_complete never fires within a defined window, that's a signal. You can trigger a follow-up task in your project management tool, flag the deal in your CRM, or push a Slack reminder to the account owner. This isn't about pestering signers — it's about giving your team the right signal at the right moment.

signer_declined deserves its own handler. When someone declines, the workflow shouldn't just stop — it should create a task, notify a human, and potentially log the reason if your flow captures it. A declined document is a recoverable situation if your system responds intelligently.

Voided Documents and Workflow Cleanup

document_voided is the event most teams handle badly or not at all. If a contract gets voided after a deal falls through or a document is replaced, any downstream automations tied to that envelope need to be unwound or suppressed.

Concretely: if you've already created an onboarding record in anticipation of completion, a void event should mark it inactive or trigger a review. Ignoring void events creates ghost records — deals that look active in your CRM but have no valid contract behind them.

Wire up a dedicated handler for document_voided that does three things: marks the related record as void in your system of record, notifies the deal owner, and prevents any queued automation steps from firing. Treat it with the same weight as a completion event.

The Cost Reality of API-Driven eSignature Workflows

Here's where pay-per-use pricing changes the architecture conversation. Subscription-based eSignature tools charge per seat or per tier, which means your API costs are fixed regardless of volume. That sounds safe until you're running an agency workflow where some months you send 400 envelopes and some months you send 40.

**With