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 Dropbox Sign 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:

‍

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:

‍

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 Dropbox Sign 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:

‍

‍

Other resources on this topic:

Example Dropbox Sign 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