Webhooks
Webhooks allow you to build or set up applications which subscribe to certain events associated with your OAuth application. When one of those events is triggered, Signeasy will send an HTTP POST payload to the webhook's configured URL.
Webhooks can be used to update your internal or external dashboards, trigger sales workflows, update a document archive, or even trigger a 3rd party workflow. You're only limited by your creativity.
Create a webhook
You can create and configure a new callback URL by logging into your developer portal and navigating to the webhooks tab of your application. Please note that Signeasy expects a 200
HTTP response status code within 30 seconds from the webhook receiver.
Subscribe to callback events
In the create webhook interface, you'd be able to provide your webhook endpoint URL and subscribe to the callback events associated with the e-signature lifecycle.
Events
The following events trigger a callback to the webhook you have configured for your or your users' account. All webhook events are processed asynchronously. Hence, the order of the events is not guaranteed.
Request signature events
Event Name | Description |
---|---|
rs.initiated | Any time a new signature request is initiated by the user. |
rs.link_sent | When the document recipients receive their link to sign the document in their email inbox. |
rs.viewed | Any time a recipient views the document they have been asked to sign. |
rs.signed | When one of the recipients signs the document. The pending document is not yet complete. |
rs.declined | When a recipient declines to sign the document. |
rs.voided | When the user voids the signature request of a document. |
rs.reminded | When the user sends a reminder to the signers of the document. |
rs.completed | When all the recipients of the document have completed signing. |
document.signed | When a user completes self-signing using the embedded self-sign flow. |
rs.bulksign_completed | When a bulk signing is completed. |
rs.bulksign_declined | When a bulk signing is declined. |
rs.expired | When the signature request is not complete within the specified expiration period. |
Each event type has a specific payload format with the relevant event information.
In addition to the information related to the signature request, webhook payloads include the user who performed the event (event_user) and the app that the event originated from (if applicable).
Retry policy
Starting from August 19th, 2023, all 3xx
, 4xx
, and 5xx
HTTP response status codes from the webhook receiver will be considered as a webhook failure.
Upon a failure, Signeasy will follow an exponential backoff strategy and retry the failed events over a period of 24 hours as follows.
Retry attempt | Time |
---|---|
1 | 2 minutes after the first failure |
2 | 4 minutes after the previous failure |
3 | 8 minutes after the previous failure |
4 | 16 minutes after the previous failure |
5 | 30 minutes after the previous failure |
6 | 1 hour after the previous failure |
7 | 2 hours after the previous failure |
8 | 4 hours after the previous failure |
9 | 6 hours after the previous failure |
10 | 10 hours after the previous failure |
You will receive an email alert when the 3rd retry fails around 8 minutes.
After continuous failures beyond this 24-hour window, the webhook will be automatically disabled with an email alert, and no new events will be processed.
To manually enable the webhook again, please fix the webhook and make sure it responds with a 200
HTTP status response code and log in to the developer portal to enable the webhook. Upon re-enabling the webhook, events that are generated between the first failure of the webhook and when we disabled it would be retried automatically. If that fails again, the retry cycle will be repeated.
Updated over 1 year ago
Payloads of all webhook callbacks