Docs not loading for Customers

---

Linda333 wrote:

...

Is there a limit?

...

---

Hi Linda333,

There is not explicit limit, but on heavy load API handlers may refuse execute some requests. Even more, since change requests to particular namespace are serialized: if there is some request already executing on the namespace you're trying to access, your request may gets delayed and rejected too. Such requests can come from your own application or any other application accessing the same namespace. It's impossible to predict if/when such thing will happen and should be ready to handle the situation if/when happens.

---

Linda333 wrote:

...

Any suggestions as to how to resolve please?

...

---

There are 2 directions to solve this. First is to decrease probability such thing to happen. Decrease the number of changing call to Dropbox as much as possible. Changing call is a call that in fact changes the structure and content of account folder' tree. So, if you have multiple uploads or moves or copy etc. operations at the same time, don't  execute it sequentially, but batch them - there will be one changing call per batch, so decreased probability for calls conflict. Second thing, you can do, is to handle the same call after reasonable delay. Usually such a delay is noted in the error response (as a header) and when so, follow the time delay there. When such delay is missing in response, do exponential back off.

Hope this gives directions

Linda333 That's correct, the Dropbox API does have a general rate limiting system that applies to all account types, but we don't have specific rate numbers documented for that, and we cannot increase the limits for any particular app, user, or team. Apps should be written to handle these rate limit responses automatically. Also note that not all responses with a 429 or 503 status code indicate explicit rate limiting, but in any case that you get a response with 429 or 503 status code 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. I recommend referring to the error documentation and Error Handling Guide for more information.