Skip to main content

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 as POST requests with a JSON body:

Headers

Verifying Requests

Compare the X-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