Rate Limiting FAQ

Updated on Wed, 2012-08-22 08:55

If you have another question which isn't answered let us know in Discussions.

Where can I find information about what rate limiting is?

Our developer resources website contains general information about rate limiting.

Are rate limits per user, per computer or per application?

Rate limits apply in different ways. Some methods are rate limited whilst others are fair use limited. In the majority of methods GET (read) requests are rate limited and POST (write) methods are not. You should check the rate limited section of the documentation for the method you want to use to make sure.

We apply requests to rate limits in the following ways:

  • Rate limits for authenticated requests are applied to the user.
  • Rate limits for unauthenticated requests are applied to the IP that we see.

This means applications share the unauthenticated rate limit AND the authenticated limit. The application being used makes no difference so switching between multiple clients on the same IP offers no rate limit advantage – they will all share the same remaining requests.

Multiple user accounts in a Twitter client each have their own user rate limit but share the unauthenticated requests.

Search has it's own rate limit and as all requests are anonymous it applies to the IP we see. This means all users on the same IP share the search rate limit.

Why did Twitter choose the World Cup 2010 as a time to start dynamically rating the API

The API represents approximately 75% of the traffic that comes to twitter.com. Keeping the rates under control. This means our best chance of bringing the services back is to lower the read-load on the API.

I have a whitelisted account and cannot operate with a really small rate limit

To ensure fairness to all users of the API, the reduced rate limit is proportional to that application or users' allowance rather than a fixed value of requests.

Will there be any warning before the limit is changed?

We don't want to be turning the rate limits down and will avoid doing if we can, but Twitter can find itself overloaded without notice. If this happens we will try everything we can to restore service before adjusting the rate limits.

Restoring service has to happen quickly and means, if the rate limit has to be reduced, it will just happen. You may find yourself rate limited even when you thought you had requests left.

How long will the rate limit be reduced?

When we reduce the rate limit we will monitor how things are going and if necessary reduce the rate further. If things are looking healthier we will assess whether increase the rate limit gradually until the default limits are restored.

We will let you all know about any default rate limit changes though @twitterapi and the Developer Talk Mailing List.

What happens when the rate limit reset time is reached?

The rate limit will continue to be the same as it was before the reset time, subject to any changes we make.

How can I check the rate limit?

You can check the rate limit one of two ways.

Response headers

Every time you make a request to the API we will return the current rate status to you in the response header. You should look for the following keys:

  1. X-RateLimit-Limit: 350
  2. X-RateLimit-Remaining: 350
  3. X-RateLimit-Reset: 1277485629

Request your rate limits from the API

Make an API call to /1/account/rate_limit_status.xml or /1/account/rate_limit_status.json. You will get a response similar to:

  1. {"reset_time_in_seconds"=>1277485629,
  2.  "remaining_hits"=>350,
  3.  "hourly_limit"=>350,
  4.  "reset_time"=>"Fri Jun 25 17:07:09 +0000 2010"}

More information is available on API definition for rate_limit_status.

How do I get whitelisted?

REST & Search API Whitelisting is not provided. Resourceful use of more efficient REST API requests, authentication, and Streaming APIs will allow you to build your integration successfully without requiring whitelisting.

Steaming API Role Permissions - Submit our streaming request form and send a detailed email to api@twitter.com detailing the usage level you'd like and, again, as much detail about your application and use case as possible.