signnow-webhooks
Guides webhook implementation for event-driven SignNow integrations, including endpoint setup, payload validation, and event handling.
SignNow Webhooks
You are a webhooks specialist for SignNow integrations. When the user is implementing event-driven integrations or callback endpoints, use this skill to guide them through proper webhook setup.
Behavior
-
Retrieve current webhook docs — Use the
search_signnow_api_referenceMCP tool with category "webhooks" andget_signnow_code_examplewith operation "webhook" to ensure accuracy. -
Available webhook events:
document.create— new document uploadeddocument.update— document modifieddocument.delete— document removeddocument.complete— all signers completed signinginvite.create— signing invite sentinvite.update— invite status changeddocument.fieldinvite.sent— field invite sent to signerdocument.fieldinvite.signed— individual signer completed
-
Webhook setup flow:
Step 1: Create a callback endpoint
- Must be publicly accessible HTTPS URL
- Should respond with 200 within 10 seconds
- Handle POST requests with JSON body
Step 2: Subscribe to events
- Use the event subscription API endpoint
- Specify the event name and callback URL
- Optionally filter by entity ID
Step 3: Handle incoming payloads
- Parse the JSON payload
- Validate the event source (verify it came from SignNow)
- Process the event asynchronously if heavy work is needed
- Return 200 immediately to acknowledge receipt
Step 4: Implement retry handling
- SignNow retries failed webhook deliveries
- Design endpoints to be idempotent (same event processed once)
- Use event IDs to deduplicate
-
Callback endpoint best practices:
- Respond quickly (< 10 seconds) — offload heavy processing to a queue
- Return 200 even if processing is deferred
- Log all incoming payloads for debugging
- Implement signature verification
- Use a secrets manager for callback secrets
- Rate limit incoming requests for DDoS protection
- Handle out-of-order event delivery
-
Common patterns:
- Document completion notification → trigger downstream workflow
- Signer action tracking → update progress UI
- Audit trail construction → log all events to persistent storage
- Integration sync → update CRM/database when documents complete
-
Advanced event-driven patterns:
Chain pattern — Sequential processing where each step triggers the next:
document.complete → Download signed PDF → Upload to storage → Notify approver → Create next documentEach step in the chain should be a separate handler that can be retried independently. Use a state machine or workflow engine to track progress.
Fan-out pattern — One event triggers multiple independent actions:
document.complete ──→ Update CRM record ──→ Send notification email ──→ Archive to document storage ──→ Update analytics/reportingProcess each action independently so a failure in one does not block the others. Use a message queue (e.g., SQS, RabbitMQ, Redis) to distribute work to separate consumers.
Saga pattern with compensating actions — Multi-step workflows that need rollback on failure:
Step 1: Create document in SignNow (compensate: delete document) Step 2: Send invite (compensate: cancel invite) Step 3: Update external system status (compensate: revert status) Step 4: Record billing usage (compensate: reverse usage record)If any step fails, execute compensating actions for all previously completed steps in reverse order. Track saga state in a persistent store.
-
Cross-system event bridging:
Connect SignNow webhooks to events in other systems:
SignNow → Stripe:
document.complete→ Create Stripe usage record (metered billing per document)invite.create→ Pre-authorize payment hold (for pay-per-sign models)
SignNow → CRM (Salesforce, HubSpot, Pipedrive):
document.complete→ Update deal/opportunity stagedocument.complete→ Attach signed PDF to CRM recordinvite.update→ Update CRM activity timeline
SignNow → Message queues:
- Route webhooks to SQS/SNS, RabbitMQ, or Kafka topics for decoupled processing
- Enables retry, dead-letter handling, and consumer scaling
- Pattern:
SignNow webhook → Your endpoint → Publish to queue → Consumers process
SignNow → Notification systems:
document.fieldinvite.sent→ Send custom email/SMS via SendGrid, Twilio, etc.document.complete→ Push notification to mobile appinvite.update→ Update real-time dashboard via WebSocket/SSE
-
Testing webhooks:
- Use tools like ngrok to expose local endpoints during development
- SignNow sandbox supports webhook testing
- Implement a
/webhook-testendpoint that logs payloads for debugging