Webhooks
sajn can send webhook notifications to your server when events occur in your account. This allows you to build integrations that react to document signings, contact changes, identity checks, and more.Setup
Webhooks are configured per workspace under Settings > Developer > Webhooks. When creating a webhook you provide:
The URL is validated on creation — sajn will resolve the hostname, block private/internal IPs (SSRF protection), and send a test POST to confirm the endpoint is reachable.
Request Format
All webhooks are sent asPOST requests with a JSON body:
Headers
Verifying Requests
Compare theX-Sajn-Secret header value against the secret you configured when creating the webhook. Reject requests that don’t match.
Handling New Fields
Payloads gain fields over time as sajn adds features. Adding a field is not treated as a breaking change, so your endpoint must ignore keys it does not recognise. Most JSON parsers do this by default; strict deserialisers do not, so check the ones that reject unknown properties —zod schemas using .strict(), Pydantic models with extra="forbid", JSON Schema validation with additionalProperties: false, Go’s DisallowUnknownFields(), and Jackson, where FAIL_ON_UNKNOWN_PROPERTIES is enabled unless you turn it off.
Existing fields are never removed or retyped without a new API version.
Delivery
- Webhooks are dispatched asynchronously via a background job queue.
- Each webhook call is logged with request/response details and kept for 72 hours.
- If delivery fails (network error or non-2xx response), an in-app notification is sent to organization members who have enabled webhook failure notifications.
- There is no automatic retry. If delivery fails, you can inspect the call log in the dashboard and resend manually or handle it on your end.
Events
Document Events
These events fire on document-level state changes. The payload is a Document object.Party Events (per signer)
These events fire when a specific party takes action. The payload is a Document + Party object.Reminder Events
Reminder events also use the Document + Party object.Identity Check Events
These events fire during the identity verification flow. The payload is an Identity Check object.Contact Events
These events fire when contacts are modified. The payload is a Contact object.Template Events
Workspace Events
A handful of enum values exist in the schema but never fire and cannot be
subscribed to:
DOCUMENT_OPENED (legacy — use DOCUMENT_PARTY_OPENED),
DOCUMENT_RECREATED (retired — the in-place update fires DOCUMENT_MODIFIED
instead), and WORKFLOW_STARTED / WORKFLOW_COMPLETED / WORKFLOW_FAILED
(reserved for the workflows beta).Payloads
Document Payload
Used by document-level events (DOCUMENT_CREATED, DOCUMENT_SENT, DOCUMENT_SIGNED, DOCUMENT_COMPLETED, DOCUMENT_REJECTED, DOCUMENT_EXPIRED, DOCUMENT_WITHDRAWN).
Party object:
Document + Party Payload
Used by party-level and reminder events. Wraps the document payload with the specific party that triggered the event.Identity Check Payload
Used by identity check events (ID_CREATED, ID_SENT, ID_OPENED, ID_VERIFIED, ID_FAILED, ID_CANCELED).
Contact Payload
Used by contact events (CONTACT_CREATED, CONTACT_UPDATED, CONTACT_DELETED).
Company object:
Next Steps
Managing Webhooks via API
Create, list, update, and delete webhooks programmatically
Event Reference
Learn about all document events

