Encountering error 429 while querying for full list of followers


#1

I am writing some code to retrieve a full list of a user’s followers, using the GET followers/ids API, as documented here:
https://developer.twitter.com/en/docs/accounts-and-users/follow-search-get-users/api-reference/get-followers-ids

I am using my own @SKZCartoons account to test this because it has over 6000 followers and I want to ensure that my code to handle multiple calls works (each call being limited to 5000 IDs). I ran it a couple of times, and it worked just fine.

To give the code a bit of a better test, I reduced the “count” parameter to 1000. The code ran just fine but the next time I ran it, I encountered error 429 “too many requests”.

Each request completes before the next one is issued from my client code (it has to, because I need the next_cursor_str in order to issue the next request).

Clearly something is wrong in my code, because Twitter is barfing.

What might cause this to happen?

EDIT obviously, exceeding the rate limit causes this. But I cannot find any details on what the rate limits are for this API call.

Is there a way to run test calls? A non-live system? Limiting this to 15 calls every 15 minutes (I am assuming that’s the limit) will slow my development, and might end up getting my app blocked!

EDIT 2 found the rate limits page. Yeah. 15 calls per 15 mins. So I need to slow my dev or test against a test system. Is there one?

https://developer.twitter.com/en/docs/basics/rate-limits.html

EDIT 3 for anyone coming after me, there is also an API call which returns the total and the remaining requests for the current application. Looks like I have to find a way to build this in. Very doable, cos all my calls go through a central class - I just need that to make sure it is not exceeding rate limits before sending a call.

https://developer.twitter.com/en/docs/developer-utilities/rate-limit-status/api-reference/get-application-rate_limit_status


#2

There’s an easier way to check your rate limits, which is to check the X-Rate-Limit-Remaining HTTP header on the response to your API call. That will save you making an additional call to the application/rate-limit-status endpoint.


#3

Thanks! I’ll check that out.