DropboxRateLimitError Threshold

[Jiho P.]

Hi, we're developing (pre-production) and have DropboxRateLimitErrors on our requests. This happens more often when we try to get thumbnails for a gallery (and quickly cancelling them as user scrolls down).

It seems like the treshold of the rate limit is pretty low. What is the actual limit you guys use? Also, is this going to be different once we get approved for production?

Thanks!

[Greg-DB]

The Dropbox API does have a rate limiting system, but we don't have any specific numbers documented. The limits operate on a per-user basis, and aren't different in production.

It sounds like you could use a batch endpoint for thumbnails, so I'll send this along as a feature request for that.

Also note that not all 429s or 503s indicate 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.

[Jiho P.]

Okay. I'm trying to wrap my head around to see if batching thumbnail requests solve the rate limit issue, but I guess it can't hurt. Few more questions:

1. Does dropbox library have a support for retrying 429 requests? Some configuration or retry module I can utilize?

2. Is the rate limit same before & after getting production approved?

Thanks!

[Greg-DB]

1. This sounds like the same question as in your other thread, so I'll follow up there:

https://www.dropboxforum.com/t5/API-support/API-v2-objective-c-rate-limit-error-hadling-configuratio...

2. Production status doesn't affect the rate limiting system.

[Greg-DB]

The Dropbox API now offers the ability to get thumbnails in batches. In the Objective-C SDK, that's available as:

https://dropbox.github.io/dropbox-sdk-obj-c/api-docs/latest/Classes/DBFILESUserAuthRoutes.html#/c:ob...: