Events Walkthrough

This walkthrough covers how to build with Dropbox Sign Events and Callbacks (aka “webhooks”), which are payloads of event metadata automatically sent to your app when something happens in Dropbox Sign.

This resource centers implementation details, examples, and building with webhooks. For a higher-level overview of Dropbox Sign Events, please refer to the Events Overview section of the documentation.

Event Scoping

When using the Dropbox Sign API, events can occur in two contexts: at the Account level and at the App level. Events that are scoped to an Account are called Account Callbacks while events scoped to an App are called App Callbacks. We recommend referring to their respective pages for more detailed information.

Account Callbacks

Account Callbacks notify your app when an event happens involving your account by sending the event payload to your account callback url. The account callback url can be configured on the Dropbox Sign website or by calling the Dropbox Sign API. You can see examples of both in the Set Account Callback Url section of this walkthrough.

App Callbacks

App Callbacks are triggered when an event happens that is associated with a specific app. When these events occur, Dropbox Sign sends the event to the app callback url. Your Dropbox Sign account can have multiple API apps that each have their own app callback url. When an event is triggered by an API request that includes a client_id, the event payload is sent to that specific app’s callback url. You can change an app callback url through the Dropbox Sign website or Dropbox Sign API. There are examples of both in the Set App Callback Url section of this walkthrough.

Setting Up Dropbox Sign Events

Enabling Dropbox Sign Events (webhooks) requires two distinct steps:

1. Setting the callback url at the account or app level, which are both covered in the sections directly below.
2. Responding to the event to verify it was received.

Set Account Callback Url

• You can change your account callback url with the Dropbox Sign API by sending a PUT request to /account and passing a callback_url.

  $
    curl -X POST 'https://api.hellosign.com/v3/account' \
  >
      -u 'YOUR_API_KEY:' \
  >
      -F 'callback_url=https://example.com/hs-account-events'

• Alternatively, your account callback url can be changed from your API settings page.

  

Set App Callback Url

• Your app callback url can be changed by sending a callback_url parameter in a PUT request to /api_app/{client_id}.

  $
    curl -X POST 'https://api.hellosign.com/v3/api_app/0dd3b823a682527788c4e40cb7b6f7e9' \
  >
      -u 'YOUR_API_KEY:' \
  >
      -F 'name=Your Awesome App' \
  >
      -F 'callback_url=https://example.com/hs-app-events'

• In the Dropbox Sign web app, you can change your app callback url from the API app’s setting page, which you can navigate to from the API settings page.

  

Responding to Events

Dropbox Sign sends events to a callback url and expects a specific response in order to verify that events are being sent to a live server. Once an event is sent, the callback url must return an HTTP 200 with a response body that contains the string Hello API Event Received. If no response is received, Dropbox Sign considers that a failed callback and the event will be sent again later.

Here’s a basic example in Nodejs:

1
// This sample is stripped down
2
// Use for reference only
3
const express = require('express');
4
const app = express();
5
6
app.post('/hs-events', (req, res) => {
7
    res.set('content-Type', 'text/plain');
8
    res.status(200).send('Hello API Event Received');
9
});

Testing your Callback Url

When setting the callback url for your app or account in the Dropbox Sign web UI, you can trigger a test event by clicking the test button next to the field. This is a great way to verify that your webhook handler is responding to events successfully.

Successful response

Failed response

Callback Request Format

Once you’ve setup a callback url, Dropbox Sign sends event data to that URL in the form of POST requests. This section contains information about how those requests are formatted so you can better understand how to interact with the event data.

Content Type

By default, the POST requests are sent as multipart/form-data with the event details in a field named json.

All of our current SDKs include an Event Callback Helper to facilitate parsing event data.

Event Payload

Event payloads always include an event field, which contains basic information about the event that occurred (such as time and type). Event payloads may include an account, signature_request, or template depending on what event took place.

Here’s an example of an event payload for a signature_request_sent event:

1
null

Event Type

Every event payload contains an event_type parameter that provides the name of the specific event that occurred:

1
{
2
    "event": {
3
        "event_time": "1348177752",
4
        "event_type": "signature_request_sent",
5
        "event_hash": "3a31324d1919d7cdc849ff407adf38fc01e01107d9400b028ff8c892469ca947",
6
        "event_metadata": {
7
            "related_signature_id": "ad4d8a769b555fa5ef38691465d426682bf2c992",
8
            "reported_for_account_id": "63522885f9261e2b04eea043933ee7313eb674fd",
9
            "reported_for_app_id": null
10
        }
11
    },
12
    "signature_request": {
13
        ...
14
    }
15
}

Generally speaking, checking the event_type is the best approach to filtering for specific events and automating your integration with the Dropbox Sign API. For example, we recommend using signature_request_all_signed as the best indicator that a signature request has been fully completed and can be downloaded using /signature_request/file:

1
if (event.event_type === "signature_request_all_signed") {
2
  // download completed signature request
3
}

You can see a complete list of possible events in the Event Names section of the overview page. This list will be updated as new events are added.

Securing your Callback Handler

Make sure that webhook events are originating from Dropbox Sign by using the following recommended methods.

IP Address Whitelisting

We have made a JSON file containing the full list of IP addresses that webhook events may come from available for download.

Note: This list will be automatically updated if the IP addresses change. We recommend checking this list periodically to ensure your callback handler is secure.

HTTP Headers

We provide a couple of headers on callback requests to help you identify them.

Event Hash Verification

Every event payload contains an event_hash that can be used to verify the event is coming from Dropbox Sign. By generating your own hash and comparing that against the one sent with the Dropbox Sign event, you can ensure you’re only processing events that you know were sent by Dropbox Sign.

The mechanism being used here is called HMAC, which stands for “hash-based message authentication code”. To generate your own hash, you’ll need to use your API key (on your API settings page) as well as the event_type and event_time from the event payload:

1
echo -n $event_time$event_type | openssl dgst -sha256 -hmac $apikey

SDK Event Callback Helper

Our current SDKs have helper methods which can help verify callbacks came from Dropbox Sign.

Below are examples on how to implement these for each of our official SDKs:

1
<?php
2
3
require_once __DIR__ . "/vendor/autoload.php";
4
5
// use your API key
6
$api_key = "YOUR_API_KEY";
7
8
// $callback_data represents data we send to you
9
$callback_data = json_decode($_POST["json"] ?? [], true);
10
11
$callback_event = Dropbox\Sign\Model\EventCallbackRequest::init($callback_data);
12
13
// verify that a callback came from HelloSign.com
14
if (Dropbox\Sign\EventCallbackHelper::isValid($api_key, $callback_event)) {
15
    // one of "account_callback" or "api_app_callback"
16
    $callback_type = Dropbox\Sign\EventCallbackHelper::getCallbackType($callback_event);
17
18
    // do your magic below!
19
}

Failures and Retries

If your callback url is not reachable or returns a non-successful response, we will retry POSTing the event up to 6 times, with each retry interval being longer than the previous one. If the sixth retry fails, you will begin receiving notifications by email.

After 10 consecutive failures, your callback URL will be automatically cleared.

Please note that our requests will timeout after 30 seconds, so callbacks will fail if your server takes longer than that to respond. The retry pattern is described below.

The above retry pattern may not always be exact, but it is a good approximation of the retry pattern we use.

Resources

• https://sign.dropbox.com/blog/using-hellosign-api-callbacks