Tips to avoid being Rate Limited
The tips below are there to help you code defensively and reduce the possibility of being rate limited. Some application features that you may want to provide are simply impossible in light of rate limiting, especially around the freshness of results. If real-time information is an aim of your application, look into The Streaming APIs along with User streams.
Caching
Store API responses in your application or on your site if you expect a lot of use. For example, don’t try to call the Twitter API on every page load of your website landing page. Instead, call the API infrequently and load the response into a local cache. When users hit your website load the cached version of the results.
Prioritize active users
If your site keeps track of many Twitter users (for example, fetching their current status or statistics about their Twitter usage), consider only requesting data for users who have recently signed into your site.
Adapt to the search results
If your application monitors a high volume of search terms, query less often for searches that have no results than for those that do. By using a back-off you can keep up to date on queries that are popular but not waste cycles requesting queries that very rarely change. Alternatively, consider using the The Streaming APIs and filter on your search terms.
Use application-only auth as a “reserve”
Requests using Application-only authentication are evaluated in a separate context to an application’s per-user rate limits. For many scenarios, you may want to use this additional rate limit pool as a “reserve” for your typical user-based operations.
Blacklisting
We ask that developers honor the rate limits. If you or your application abuse the rate limits, the account or app will be blacklisted. If an app is blacklisted it will be unable to get a response from the Twitter API. If you or your application has been blacklisted and you think there has been a mistake, you can use our Platform Support forms. So that we can get you back online quickly, please include the following information:
If you are using the REST API, make a call to the GET application / rate_limit_status from the account or computer which you believe to be blacklisted.
Explain why you think your application was blacklisted.
Describe in detail how you have fixed the problem that you think caused you to be blacklisted.
Streaming API
The Streaming API has rate limiting and access levels that are appropriate for long-lived connections. See the Streaming APIs documentation for more details.
Leveraging the Streaming API is a great way to free-up your rate limits for more inventive uses of the Twitter API.
Rate Limiting information for the Streaming API is detailed on Connecting to a streaming endpoint.
Limits Per Window Per Resource
The API rate limit window duration is 15 minutes long. Visit the API Rate Limit: Chart page to see the limits by resource.
Note that endpoints/resources not listed in the above chart default to 15 requests per allotted user.
https://dev.twitter.com/rest/public/rate-limiting
The tips below are there to help you code defensively and reduce the possibility of being rate limited. Some application features that you may want to provide are simply impossible in light of rate limiting, especially around the freshness of results. If real-time information is an aim of your application, look into The Streaming APIs along with User streams.
Caching
Store API responses in your application or on your site if you expect a lot of use. For example, don’t try to call the Twitter API on every page load of your website landing page. Instead, call the API infrequently and load the response into a local cache. When users hit your website load the cached version of the results.
Prioritize active users
If your site keeps track of many Twitter users (for example, fetching their current status or statistics about their Twitter usage), consider only requesting data for users who have recently signed into your site.
Adapt to the search results
If your application monitors a high volume of search terms, query less often for searches that have no results than for those that do. By using a back-off you can keep up to date on queries that are popular but not waste cycles requesting queries that very rarely change. Alternatively, consider using the The Streaming APIs and filter on your search terms.
Use application-only auth as a “reserve”
Requests using Application-only authentication are evaluated in a separate context to an application’s per-user rate limits. For many scenarios, you may want to use this additional rate limit pool as a “reserve” for your typical user-based operations.
Blacklisting
We ask that developers honor the rate limits. If you or your application abuse the rate limits, the account or app will be blacklisted. If an app is blacklisted it will be unable to get a response from the Twitter API. If you or your application has been blacklisted and you think there has been a mistake, you can use our Platform Support forms. So that we can get you back online quickly, please include the following information:
If you are using the REST API, make a call to the GET application / rate_limit_status from the account or computer which you believe to be blacklisted.
Explain why you think your application was blacklisted.
Describe in detail how you have fixed the problem that you think caused you to be blacklisted.
Streaming API
The Streaming API has rate limiting and access levels that are appropriate for long-lived connections. See the Streaming APIs documentation for more details.
Leveraging the Streaming API is a great way to free-up your rate limits for more inventive uses of the Twitter API.
Rate Limiting information for the Streaming API is detailed on Connecting to a streaming endpoint.
Limits Per Window Per Resource
The API rate limit window duration is 15 minutes long. Visit the API Rate Limit: Chart page to see the limits by resource.
Note that endpoints/resources not listed in the above chart default to 15 requests per allotted user.
https://dev.twitter.com/rest/public/rate-limiting