Child Item

Status 429 Rate Limiting very frequent

I have an Android application that gets the Dropbox photos the user has and then it can send the Dropbox oauth token to a web service so that web service gets the photos and extracts the Metadata and saves to a server database.

Everything was working great, photos were downloaded from Dropbox using several threads at the same time and no rate limiting responses. But now even with one thread, it gets several rate limiting responses. When I mean several it is 90% of the requests. Why is this happening? Did something change?

It makes no sense since in the Android app after using Delta to retrieve the Dropbox status the photos are get using a multithreading library and it never gets rate limiting responses. Is it because of using the token outside the app?

Find more posts tagged with

API

Abuse

Comments

Greg-DB

Where you use an access token shouldn't really affect this. Do you have a basic idea of the rate at which you are making calls? The rate limiting system is generally pretty generous. It also works per-user, so are you seeing this only for a specific user(s)? If so, it may be due to the user(s) having many more files or more activity than is typical.

It may be more useful for us to look into this for you specifically, so feel free to open a ticket with the details if you'd prefer:

https://www.dropbox.com/developers/contact

Tiago S.6

Thank you Greg for the response.

The problem might be then with the per user limiting because it is a single web service downloading all the photos and processing them. I am still in development stage so for the Android app it is only one user also.

The strange thing is that in the Android app there is no problem with the rate. It just gets all the photos no problem, and currently I have 1000+ photos there. When I send the token to the web service it then tries to get the photos that it didn't process before. In the first run it will always get 1000+ photos.

I am trying to get the same behavior as an app like PictureLife when it connects to Dropbox it fetches the information from the photos.

The biggest issue is that this worked well before, it fetched the photos even with 10 threads at the same time, and the same huge number. But now it gives a huge amount of 429 statuses.

Greg-DB

One thing that may explain some of the disparity is that the web server may be able to make calls at a much faster rate than the Android device can.

Can you check what rate you are making the calls at when you see this though? And in any case, when you get one of these responses, the best thing to do is to check and respect the Retry-After header in the response, which should tell you how many seconds to wait before calling again for that user.