Rate Limits Query?

[twoostly]

Let’s say I have 100 users on my app, do each of these 100 users get their own individual API rate limits or is the API rate limit on a per application basis?

[andypiper]

This is explained in the documentation. If the users are authenticated, then each user token will have its own set of rate limits. This is the difference between operating with a user context, and an application-only context. This is why the rate limits page lists two columns.

[twoostly]

Thanks Andy. The reason for asking is Twitter finally responded but now I have questions for them so assume I’ll be sat here waiting another 72hrs for a response.

One of the things they said was: “Further, your most recent day of API usage is showing nearly 20,000 rate limited calls. This is abusive API usage, and it must stop. Please outline your plan for ensuring that this does not happen again.”

Hence the question here on the Twitter Community as we cannot work out where we’re actually exceeding rate limits.

[IgorBrigadir]

your most recent day of API usage is showing nearly 20,000 rate limited calls. This is abusive API usage, and it must stop.

Sounds like you keep making requests even after getting a “Rate Limit Exceeded” or other error - if i’m reading that right.

Is there maybe some code that keeps retrying on errors that’s causing this? What rate limits are you working on - the ratelimits from the https://dev.twitter.com/rest/reference/get/application/rate_limit_status endpoint or the HTTP headers?

I’ve always used the HTTP header ratelimits, and never had any problems with those (rate_limit_status response sometimes shows you have a few requests remaining when you don’t, it’s “slower” to update in my experience, but useful to fill in initial values for rate limits)

Another thing to check is if you’re making requests in parallel - this is a bad idea, i tried it before, and you end up with very unpredictable results, and lots of rate limit exceeded errors. ie: if you have 15 calls in a 15 min window to make for a user, make those one after another, never in parallel, and keep an eye on the ratelimit http headers, also a good idea to always add a few extra seconds of wait time on top of what twitter reports as the “reset time” to be on the safe side.

Also, given 100 users - i’m sure some of them will end up revoking access, invalidating their tokens. Making requests on behalf of those users will also look like “abusive API usage”. You should check that with https://dev.twitter.com/rest/reference/get/account/verify_credentials before launching a bunch of API calls on behalf of that user, since they might have revoked app access at some point between signing up - where you got their access token, and began making API calls.

Sounds like you should be fine if you manage to fix the rate limited calls.