You go out for dinner and, coincidentally, 50 other people decided to go to the same restaurant at about the same time, so you get to the waitlist. Do you know why we need to form a line to get a table at the restaurant? That’s right! It’s because there’s a “maximum occupancy” the restaurant can hold (I’m sure you’ve seen these little signs). The occupancy limits exist in all public venues to ensure public safety.

‍

Similarly, the Dropbox Sign API uses a system called "rate limits" to ensure the stability of the API to service the client request.

‍

Each time the Dropbox Sign API is hit, regardless of the verb used, it counts as an API request. If your application makes a lot of API requests in a short amount of time, you may bump into the API rate limit. You will know this has happened when you get an error message like the following:

Or an email like this:

When you reach the limit, the Dropbox Sign API stops processing any more requests until the required amount of time has passed. The rate limits for a DropboxSign account are outlined in the Rate limits section of the API documentation.

‍

This article is intended to define best practices for avoiding rate limiting in the Dropbox Sign API.

Reducing the number of API requests

First and foremost, make sure your application is making only the requests that it needs. Here are some ideas to explore to optimize your code to eliminate any unnecessary API calls:

1. Avoid polling the API, use Callbacks instead. An example of this is when retrieving the final document after a signature request has been completed: once the document has been signed, it still needs to be processed; how long this processing takes varies. If you call for the document too soon, you’ll get a “document is still processing” response and you will need to wait and try again later. This “try again later” means additional API calls that will consume your rate limits. Instead, you’ll want to listen for the "signature_request_all_signed" callback event, which is triggered only once the final file is processed and ready to be downloaded, and tie the document download to it. This way you will be making only one API call that will work for sure.
2. Cache your own data when you need to store specialized values or rapidly review very large data sets. You can also save static information in a database or even serialize it in a file. For example, if your site allows users to browse your template library, you’ll want to have your templates stored in a database and pull the template list from there instead of making an API call every time the user needs to choose a template. This would not only reduce the risk of hitting a rate limit in the way but also improve performance, not to mention reducing the dependency to the API itself. In an implementation like this, you'd only need to call the API to update your database with new templates - or even better, listen to the "template_created" callback event and have your app do it automatically without even needing to call the API-.
3. Ask yourself, are there requests getting data items that aren't used in my application? What am I using that “signature request list” call I’m making every time a user gets to this page for?
4. Use bulk endpoints such as Bulk Send with Template, which lets you sends up to 250 signature requests in bulk with a single API request, instead of making 250 “Send with Template” calls.
5. If you need to backfill data, consider doing it in batches. For example, currently the best approach to download your document library is to use the API. A good way to do it is setting it up as a script and run the script in batches with wait times that will respect the rate limit.

Monitoring API activity

You can use the API dashboard in the DropboxSign portal to monitor your API activity against your limits:

‍

You can also consider including a process in your code that regulates the rate of your requests so that they're distributed more evenly over time. For this you could, for example, use the following API response headers to confirm your account's current rate limit and monitor the number of requests remaining in the current period:

These headers are included by default in every response our API sends to your application.

Catching errors caused by rate limits

Ideally, your application handles the rate limit exception gracefully instead of crashing (ideally, right?).

‍

As a best practice, make sure to notify the user of the situation. Depending on the workflow that’s being executed, you’ll want to let them know that the application isn’t broken and that there’s hope: they’ll be able to retry the operation. Usual example messages are similar to:

‍

Questions? Reach out!