Skip to main content

Overview

Webhooks let your application receive real-time notifications when events happen in DocuTrust. Instead of polling the API, DocuTrust sends an HTTP POST request to your configured endpoint whenever a relevant event fires. Each webhook delivery includes a JSON payload describing the event, a cryptographic signature for verification, and a unique delivery ID for deduplication.

Supported Events

DocuTrust emits 14 event types across four resource categories:

Form Events

Triggered when a submitter interacts with a signing form.

Field Events

Submission Events

Triggered when the overall submission (containing one or more submitters) changes state.

Template Events

Event Payloads

Every webhook delivery is an HTTP POST with Content-Type: application/json. The top-level structure is always:

Form Event Payload

All form events (form.created, form.started, form.viewed, form.completed, form.declined, form.expired) share this structure:
For form.declined events, the declined_at field will contain a timestamp and completed_at will be null. For form.expired events, both completed_at and declined_at will be null.

Submission Event Payload

Submission events include the full list of submitters and their statuses:
Submission event metadata echoes the caller-provided submission metadata. Keys reserved for DocuTrust internals, currently flattening_failed, are omitted. Submitter metadata remains excluded; use each submitter’s external_id for caller-owned correlation.

Document download URLs in payloads

The submission.completed and form.completed webhook payloads include a documents array with download URLs, so you can retrieve signed PDFs directly from the event without a follow-up API call:
The download_url requires authentication (Bearer token or X-Auth-Token with submissions:read scope).

Template Event Payload

Template events include metadata about the template’s structure:

Field Updated Payload

Fired each time a submitter changes a field value. Includes the old and new values for change tracking:

Webhook Headers

Every webhook delivery includes the following HTTP headers:

HMAC Signature Verification

Every webhook includes an X-Webhook-Signature header containing an HMAC-SHA256 digest of the raw request body, signed with your webhook secret key:
Always verify the signature before processing a webhook to ensure it was sent by DocuTrust and was not tampered with in transit.
Always use the raw request body (bytes) for signature verification, not a parsed or re-serialized version. Re-serializing JSON may change key order or whitespace, causing verification to fail.

Managing Webhooks via API

Create a Webhook Endpoint

Response:

Update a Webhook Endpoint

Response:

List All Webhook Endpoints

Response:

Delete a Webhook Endpoint

Returns HTTP 204 No Content on success.

Webhook Delivery Log

Retrieve the delivery history for a specific webhook endpoint. Each entry includes the HTTP status code, response time, payload, and any error details.
Query parameters: Response:
Delivery object fields:

Redelivering a failed webhook

If a delivery failed or was exhausted, you can trigger a redeliver:
This creates a new delivery attempt with a fresh delivery_uuid.

Test a Webhook Endpoint

Send a test delivery to verify your endpoint is working correctly.
This sends a sample payload to your registered URL with realistic test data. The delivery includes all standard headers so you can verify your signature validation logic.

Retry Policy

If your endpoint does not return an HTTP 2xx response, DocuTrust retries the delivery up to 5 times with increasing delays: After 5 failed attempts, the delivery is marked as permanently failed. You can view failed deliveries in the webhook logs section of your account settings. Timeout thresholds:
  • Connect timeout: 5 seconds. If DocuTrust cannot establish a TCP connection within 5 seconds, the attempt fails.
  • Read timeout: 10 seconds. If your server does not send a complete response within 10 seconds of connection, the attempt fails.
Each retry includes the same X-Webhook-Delivery-Id, so you can use it to deduplicate deliveries on your end.
Return a 200 OK response as quickly as possible. Process the webhook payload asynchronously (e.g., via a background job) to avoid hitting the read timeout.

SSRF Protection

DocuTrust validates all webhook URLs before delivering events. The following restrictions apply to protect against Server-Side Request Forgery (SSRF) attacks: Blocked IP ranges: Additional restrictions:
  • HTTPS required in production. HTTP URLs are only accepted in development/test environments.
  • Localhost blocked. URLs containing localhost, 127.0.0.1, or [::1] are rejected.
  • Cloud metadata endpoints blocked. URLs targeting 169.254.169.254 and similar metadata service IPs are rejected.

Best Practices

Always validate the X-Webhook-Signature header before processing any webhook payload. Never skip verification, even in development.
Store the X-Webhook-Delivery-Id header value and check for duplicates before processing. Retries will send the same delivery ID.
Return a 200 status immediately and enqueue the payload for background processing. Long-running synchronous handlers risk timeouts and unnecessary retries.
Your webhook handler may receive the same event more than once due to retries. Design your processing logic to be safe for repeated execution.
Selecting specific events reduces traffic to your endpoint and simplifies your handler logic. You can always add more events later.
Set up alerting for elevated error rates or slow response times on your webhook handler. DocuTrust will stop retrying after 5 failures.