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
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:
What’s a Rich Text element?
The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.
Static and dynamic content editing
A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!
How to customize formatting for each rich text
Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.