App name: Inpsyde BackWPup App / Inpsyde BackWPup
Details:
Hello, some of our Users get the message:
(429) Your app is making too many requests and is being rate limited. Error 429 can be triggered on a per-app or per-user basis. Wait for 5 seconds.
I know that the old API Keys could handle many more API Requests without this message. Can you change that for our App keys?
Regards
Daniel Hüsken – Product Owner
—
Moe, Mar 2, 10:32 AM PST:
Hi,
The Dropbox API does have a general rate limiting system, but we can’t increase the limits for any particular app, user, or team. That being the case, can you elaborate what you mean when you say “the old API Keys could handle many more API Requests without this message”? The limits should apply the same to all of your apps. If you had a previous discussion with Dropbox that indicated otherwise, please share the ticket ID so I can check on that for you.
Rate limiting can vary over time since it can also be a result of other user activity. In any case, 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. You should also check the actual response body from the Dropbox API call for more information. The error message you included here doesn’t seem to include the actual error response from the Dropbox API, but rather is just a static message.
For example, if you’re making multiple changes at the same time in the same account or shared folder, you can run in to a ‘too_many_write_operations’ error, which is “lock contention”. That’s not explicit rate limiting, but rather a result of how Dropbox works on the backend. This is a technical inability to make a modification in the account or shared folder at the time of the API call. This error indicates that there was simultaneous activity in the account or shared folder preventing your app from making the state-modifying call (e.g., adding, editing, moving, or deleting files/folders) it is attempting. The simultaneous activity could be coming from your app itself, or elsewhere, e.g., from the user’s desktop client. It can come from the same user, or another member of a shared folder. You can find more information about lock contention here.
In short, to avoid this error, you should avoid making multiple concurrent state modifications. E.g., don’t issue multiple such requests at a time, and use batch endpoints whenever possible. That won’t guarantee that you won’t run in to this error though, as contention can still come from other sources.
Regards,
Moe