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.
