Child Item

API v2 Limits, constant 429 errors.

Looking for some advice on API call struture and rate limits.

We are currently collecting data (flat files) from over 2000 applications daily using the User API.

2 users with a number of apps apiece collecting data.

We have oAuth tokens created for each app.

We are getting specfically 429 errors and even though we increase the number of oauth tokens, reducing the number of requests per token (as per the Data Ingress Guide) we are still getitng 5-10% of requests returning the 429 error. It appears there is maybe a user limit or limit per group of apps, rather than the per oAuth token limit.

Any advice would be appreciated, please understand we have already had a number of people go through the Data Ingress Guide in details so we've already seen it and been through it!

Any relatable experience with this type of set up would much appreciated!

Thanks in advance,

Red Fox Techos

Find more posts tagged with

API

Abuse

Comments

Greg-DB

Apologies, it looks like the data ingress guide is worded a bit confusingly:

"Rate limits are applied to the OAuth access token used to make the request. For user-linked apps this means rate limits apply per user who has linked your app."

Note that the first sentence isn't written with the potential of having multiple access tokens per user in mind. (It's trying to generalize over user-linked apps versus team-linked apps.) The second sentence is more appropriate in this case. The rate limit is per-app-user.

So, if you are making calls for any particular app-user at a very high rate, you will get rate limited.

There are some special cases though, so if you're seeing rate limiting when you aren't making many calls, please feel free to share the relevant code and some sample X-Dropbox-Request-Id response header values and we can look into it to see if we can offer any advice. You can share privately by opening an API ticket here if you prefer: https://www.dropbox.com/developers/contact

redfoxpartners

Hi Greg, thanks for this feedback so this means that to spread the load so to speak, we need more user accounts to be running the app?

Or are you referring to users, as in endpoints accessing the app(uploading and downloading to\from dropbox via the app)?

Thanks for your assistance,

Greg-DB

In this context, by users I'm referring to the different Dropbox accounts, i.e., each registered to Dropbox with a different email address.

The Dropbox API was built with the intent that each end-user of your app would connect their own Dropbox account.

In the typical case, this isn't really something where you can spread the load by introducing more users. Users should each be linking to the app of their own accord, and the rate limiting will apply per-user anyway.

I don't have full context on your app though. It sounds like you may control all of the accounts connected to your app? Please feel free to elaborate, and include any relevant code snippet(s) and the full error output if you'd like me to take a look and offer more advice.