Once document signing becomes part of a larger workflow, checking GoSign manually every time something changes quickly becomes a hassle. You may need your CRM to know when a document is completed, your team to get notified when someone declines a form, or an internal system to update as soon as a submission is created.
That's where webhooks come in. They let GoSign automatically send information to another system whenever a selected event happens. Instead of repeatedly checking for updates, your other tools can receive them as they happen.
In this guide, we'll show you how to set up a GoSign webhook, choose the events you want to track, test your connection, and understand the data GoSign sends with each webhook request.
What Webhooks Are, and Why They're Useful
A webhook is GoSign telling another system the moment something happens, instead of that system having to keep checking in and asking "anything new yet?" That's the real difference. Without one, keeping a CRM or dashboard in sync means either checking GoSign manually or building something that polls it every few minutes and guesses at the right interval. With a webhook, GoSign pushes the update the second a document is signed, declined, or created, nothing sits stale, and nobody has to go looking for it.
It matters most when a signed document is supposed to trigger something else, kicking off onboarding once a contract lands, moving a deal stage in your CRM, pinging an ops channel the moment paperwork clears. That's the real use case: letting GoSign quietly plug into the rest of your stack instead of being one more tool you have to check on separately.
Where to Find It
Go to Settings → Webhooks, under the Integrations section in the sidebar. Webhooks are a paid-plan feature, so if you need to be on a paid plan to use it.
1. Add Your Webhook URL
Paste the endpoint you want GoSign to send data to into the Webhook URL field, then click SAVE. This is usually a URL from whatever tool is receiving the data, Zapier, Make, or an endpoint your own team built.
2. Choose Your Events
Below the URL are ten checkboxes, each one an event GoSign can notify you about. They fall into three groups.
Signing events track what an individual signer does: form.viewed, form.started, form.completed, and form.declined. These fire per signer, so on a document with three signers, you could get three separate form.completed events, one for each person.
Submission events track the whole envelope, not just one signer's part: submission.created, submission.completed, submission.expired, and submission.archived. Use these when you care about the document as a whole being fully signed, not just one person's step in it.
Template events fire when a template itself changes: template.created and template.updated. Useful if you're managing templates programmatically and want to know when something's been added or edited.
Check the boxes for whatever you actually plan to act on. There's no downside to selecting more, but every checked event means another payload landing on your endpoint.
3. Test Mode
Toggle Test mode on and GoSign sends a sample payload to your URL, so you can confirm your endpoint is receiving and parsing data correctly before a real signer ever touches a document. Worth doing once, right after you save your URL, rather than finding out something's broken the first time a real submission comes through.
Reading the Payload
Every webhook call sends a JSON payload. Here's a real example, triggered by a form.completed event:
{
"event_type": "form.completed",
"timestamp": "2026-08-14T06:47:54Z",
"data": {
"id": 505,
"submission_id": 414,
"email": "talha.masood@example.com",
"phone": null,
"name": "Talha Masood",
"ua": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36...",
"ip": "105.112.102.231",
"sent_at": null,
"opened_at": "2026-05-28T18:42:51.033Z",
"completed_at": "2026-05-28T18:43:06.881Z",
"declined_at": null,
"created_at": "2026-05-28T18:42:47.283Z",
"updated_at": "2026-05-28T18:43:06.948Z",
"external_id": null,
"metadata": {},
"status": "completed",
"application_key": null,
"decline_reason": null,
"role": "First Party"
}
}
A quick guide to what's in data:
Field | What it tells you |
|---|---|
| The internal ID for this signer's part of the submission |
| The ID of the overall submission this signer belongs to |
| Whatever contact details the signer was sent with |
| The signer's browser and device, pulled from their session |
| The signer's IP address at the time |
| Timestamps for each stage the signer reached |
| When this record was created and last changed |
| Your own reference ID, if you set one when sending via the API |
| Any custom key-value data attached to the submission |
| Where things currently stand: completed, in this case |
| Which party the signer is, "First Party," "Second Party," and so on |
Getting the Most Out of Webhooks
Turn on Test mode before anything else, it's a five-second check that saves you from discovering a broken endpoint days later. Pick events based on what you'll actually use, not everything, form.completed and submission.completed cover most workflows on their own. And if you're sending documents through the API, set an external_id on each submission, it's what lets you match a webhook payload back to your own records without having to cross-reference by email or timestamp.
