Utilizzo dei callback di API HelloSign

"Using HelloSign API Callbacks" header image
Lo stesso prodotto con un nuovo aspetto! HelloSign è diventato Dropbox Sign!

Let’s start by defining callbacks (otherwise known as webhooks). There are two ways two apps can communicate with each other to share information: polling and callbacks. Polling is like going on a roadtrip and asking the driver “are we there yet?” every 5 minutes. Callbacks are like falling asleep and having the driver wake you up once you are finally there.

Callbacks are automated messages sent from apps to notify that something happened. They have a payload (or body) and are sent to a unique URL.

The HelloSign API sends callbacks for the life cycle of a signature request. Instead of calling the API to check the status of a request, you can listen for these callbacks to build a reliable flow in your application.

Let’s take the example of creating a simple signature request. After you call the signature_request/create_embedded endpoint, you receive a response from the API with a status (“200” if it was successful. Otherwise, learn our error messages) and a JSON containing information pertinent to the call you made. This response is useful because it gives you basic information about the request, lets you know that our server received it successfully and there were no issues with the parameters you passed in.

Here is what is happening behind the scenes:

A diagram showing a callback with HelloSign API

If, for example, there was an issue during document processing because the uploaded document has a text tag that is malformed, this is flagged as an error and our API will want to notify you that this happened through a callback event. Wouldn’t it be nice for you to know there was an issue with your file right away instead of having to figure it out the hard way?

This is why it is a best practice to wait for the “signature_request_sent” callback (which only fires once document processing is complete) before attempting to open a sign url in the iFrame. In the case of the error we used as an example, a “file_error” callback will be sent instead. This is how an example of the “file_error” callback event will look like in the API Dashboard:

Screenshot of the "file_error" callback event in the HelloSign API dashboard
Note: to see something like the above, you need to make sure to be logged in with the  HelloSign account that owns the app the requests are being made with.

Another example of when you can benefit from callbacks is downloading the final (signed) document. The “signature_request_all_signed” callback will trigger only after all the signers have completed the document and it’s ready for download. In this case, a best practice is to wait for the “signature_request_all_signed” callback event and then trigger the document download. This ensures that you will get the final copy of the document with all signatures and the “completed” status on the audit trail.

Responding to callbacks

The HelloSign API will send callbacks to whatever URL you tell it to. You can set your account callback by using the account API call or manually on the settings page.

Your endpoint will need to return a 200 HTTP code and a response body containing the following text: “Hello API Event Received.” Otherwise, the callback will be considered a failure and will be retried later. Refer to the “Events and Callbacks” article for more information on this. To illustrate the workflow:

Diagram showing how to respond to callbacks using the HelloSign API

Other resources on this topic:

Example HelloSign API Callback Event

The difference between signature_request_signed and all_signed callback events.

Example Java Callback Handler

Simple PHP Callback Handler

A Simple Python Callback Handler

Example of how to use ngrok (or other localhost tunneling software) to test callback handlers

Tools for Testing the API and Callbacks Locally

Get news, insights and posts directly in your inbox

Grazie! Il tuo invio è stato registrato!
Si è verificato un problema durante l'invio del modulo
Si è verificato un problema durante l'invio del modulo.