cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Want to learn some quick and useful tips to make your day easier? Check out how Calvin uses Replay to get feedback from other teams at Dropbox here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

API limits on RPC endpoints

API limits on RPC endpoints

rk90
Helpful | Level 5

As per the Dropbox API doc, there limits to the API calls, but Dropbox does not wish to disclose any info on limitations.

I understand that there might be daily/monthly quota on upload/download APIs, but what are the limitations on RPC endpoints?  The reason I ask this is because, I will be doing a complete scan of pretty large Dropbox Business accounts (Thousands of members with millions of folders). Listing each folder at a time will be very time consuming and may even take days, so I plan to list multiple folders simulataneously and wanted to take advice on limits on number of concurrent list_folder requests. I ran a few tests and the behaviour was inconsistent. That is, at times I was able to list 10 folders concurrently while other times I get '429 too many requests' when trying to list 3 folders concurrently.

1 Reply 1

Greg-DB
Dropbox Staff

The Dropbox API does have a rate limiting system, but we don't have any specific numbers documented. For reference though, the limits operate on a per-user basis. 

However, note that not all 429s and 503s indicate explicit rate limiting, but in any case that you get a 429 or 503 the best practice is to retry the request, respecting the Retry-After header if given in the response, or using an exponential back-off, if not. (Generally the window isn't more than a few minutes.) The rate limiting system and parameters are subject to change, so this strategy is preferred as it produces a more dynamic way of handling rate limiting, as opposed to relying on a hard-coded number. You should also check the response body for a specific error message.

There are also some special cases that can produce rate limiting responses without excessive amounts of calls. For instance, with list_folder, some of the special cases that you might encounter:

  • If certain file metadata is not yet available at the time of the API call (e.g., for new files), you'll get a 429 and will need to call back after the (generally very short, on the order of seconds) delay indicated in the Retry-After header.
  • If you make multiple identical /2/files/list_folder[/continue] calls simultaneously (e.g., for the same user and folder), you'll get a 429 back. For those, avoid sending the duplicate calls.

 

Need more support?
Who's talking

Top contributors to this post

  • User avatar
    Greg-DB Dropbox Staff
What do Dropbox user levels mean?