Welcome to Portal

?Unknown\pull-down

Welcome to Zoho Cares

Bienvenido a Soporte de Zoho

Search our knowledge base, ask the community or submit a request.

Webhooks

Webhook is one of the popular call back mechanisms popularly used by developers to integrate any two applications. It provides updates in real-time to the integrated application whenever an event or action occurs. This is a superior solution, unlike in API based models where such data needs to be polled periodically. Webhook is a much more efficient and widely used methodology as far as integration is concerned.

Zoho Sign Webhooks

Zoho Sign provides option to configure webhooks to get real-time update of events that occur in Zoho Sign.

Event sent for
Description
Sent
Triggers when documents are sent for signatures. 
Viewed
Triggers when documents are viewed by one of the recipients.
Signed by a recipient
Triggers when documents are signed or approved by one of the recipients.
Completed by all 
Triggers when documents are completely signed and approved by all recipients.
Declined
Triggers when documents are declined by one of the recipients
Reassigned
Triggers when documents are reassigned by one of the recipients to be signed or approved by another person.
Expires
Triggers when documents are sent for signatures and the approval expires.
Recalled
Triggers when documents are sent for signatures or approval are recalled by the sender.

Prerequisites:

  1. Webhooks, at present, are available on Enterprise, API, Zoho One, and People Plus plans.
  2. Currently, only two webhooks are allowed per account.

How to register a webhook:

  1. The Zoho Sign admin can register a webhook by clicking Settings > Developer Settings > Webhooks from the left navigation pane.
  2. Click Create webhook and provide relevant information like callback URL and name. It also has a list of events for which this webhook has to be triggered.



  3. If you wish to secure your webhook, enable the HMAC signature checkbox and enter the Secret key generated by you. If you don't have one, click the Generate button.
    Once configured, the saved secret key cannot be retrieved from Zoho Sign.
    You must take necessary steps to keep the secret key safe since the secret key is needed to validate the webhook payload in your application
  4. Choose the relevant options and complete the webhook registration process.

Webhook payload:

  1. For every webhook event, following payload will be triggered.
  2. This payload is a JSON object with two keys, "notifications" and "requests", each internally containing a JSON object.
  3. The notifications object gives details about the action which was performed on the document and the requests object contains the details about the document for which the webhook was called.

Structure:

  1. {
  2. "notifications": 
  3. {
  4. "performed_by_email": "<email address of the person performing the operation. ",
  5. "performed_by_name": "<user who performed this operation",
  6. "performed_at": <time value in java current time in mills format>,
  7. "reason": "Reason stated for the operation-applicable if any",
  8. "activity": "<small description of activity performed",
  9. "operation_type": "RequestSubmitted | RequestViewed | RequestSigningSuccess | RequestCompleted | RequestRejected | RequestRecalled | RequestForwarded | RequestExpired",
  10. "action_id": "<sign action id",
  11. "ip_address": "<ip address captured during this operation>"
  12. },
  13. "requests": 
  14. {
  15. "request_status": "<status of the document>",
  16. "request_name": "<name of the sign request>",
  17. "request_id": "<long value - primary key of the signature request",
  18. "document_ids": 
  19. [
  20. {
  21. "document_name": "<name of the document inside signature request",
  22. "document_id": "<long value - of the document contained inside request"
  23. }
  24. ]
  25. }
  26. }
Sample payload:
  1. {
  2. "notifications": 
  3. {
  4. "performed_by_email": "testuser@zoho.com",
  5. "performed_at": 1555062604837,
  6. "reason": "reason given if any",
  7. "activity": "Document has been signed",
  8. "operation_type": "RequestSigningSuccess",
  9. "action_id": "1000000000090",
  10. "performed_by_name": "test user",
  11. "ip_address": "192.168.100.100"
  12. },
  13. "requests": 
  14. {
  15. "request_name": "NDA Document",
  16. "request_id": "1000000000000",
  17. "org_id": "9876543210",
  18. "request_type_id": "10000000011",
  19. "document_ids": 
  20. [
  21. {
  22. "document_name": "CommonNDA.pdf",
  23. "document_id": "100000000000050"
  24. }
  25. ]
  26. }
  27. }
Note:
  1. operation_type attribute under notification JSON object can have one of the following pre-defined constants with which actions are triggered. This attribute plays an important role in identifying the type of event that took place.
Operation Types
Reason for triggering
RequestSubmitted
When a document is submitted for signature.
RequestViewed
When a submitted document is viewed.
RequestSigningSuccess
When one of the signers successfully completes the signing process.
RequestCompleted
When all the assigned signers or approvers completes the signing or approval process.
RequestRejected
When a submitted signature request is rejected.
RequestRecalled
When a submitted signature request is recalled by the sender.
RequestForwarded
When a submitted request is forwarded to another person by the assigned signer.
RequestExpired
When a submitted document expires the allocated signing time.

  1. For signer-related actions, such as RequestViewed, RequestSigningSuccess, RequestRejected, and RequestForwarded, there will be 'action_id' of the signer present inside the 'notifications' json. 
  2. All other data that comes as part of notification payload are not standard data attributes and may be removed anytime in future. Users are advised to use documented attributes alone.



Helpful?152
Updated: 4 months ago
Share :