Rate limits

Jump to Twitter API v2 rate limits table

 

Overview

Every day many thousands of developers make requests to the Twitter API. To help manage the sheer volume of these requests, limits are placed on the number of requests that can be made. These limits help us provide the reliable and scalable API that our developer community relies on. 

The maximum number of requests that are allowed is based on a time interval, some specified period or window of time. The most common request limit interval is fifteen minutes. If an endpoint has a rate limit of 900 requests/15-minutes, then up to 900 requests over any 15-minute interval is allowed. 

Rate limits are applied based on which authentication method you are using. For example, if you are using OAuth 1.0a User Context, you will have one limit per time period for each set of users’ access tokens, while if you are using OAuth 2.0 Bearer Token, you will have a separate limit per time period for requests made by your app. When these limits are exceeded, an error is returned. Keep reading to learn more about these details and tips on how to avoid being rate limited. 

 

Rate limits and authentication method

Rate limits are set at both the developer App and the user access token levels:

  • OAuth 2.0 Bearer Token: per-developer App
    All Twitter API v2 endpoints accept this authentication method, and therefore will limit you to only make a certain number of requests to endpoints on behalf of your developer app. When using this authentication method, rate limits are determined by the number of requests you make using a Bearer Token. If an endpoint allows for 450 requests per rate limit window, then you can make 450 requests per window on behalf of your App by passing a Bearer Token. This limit is considered completely separate from the OAuth 1.0a User Context limit.

  • OAuth 1.0a User Context: per-set of user access token
    Tweet lookup and recent search allow for you to authenticate on behalf of a user. For example, if you would like to retrieve private metrics from Tweets, you would need to authenticate with the user tokens associated with that user, which can be generated by using the 3-legged OAuth flow. If ten users have authorized your developer App, and up to 900 requests per 15-minute interval can be made on behalf of each user, you should be able to make up to 9000 requests on behalf of these users. This limit is considered completely separate from per-application Bearer Token limits. 

 

Please note

Users' rate limits are shared across all apps that they have authorized and the Twitter application. For example, if a specific user likes 20 Tweets on the Twitter mobile application and likes 20 Tweets on a third-party application within a 24 hour period of time, the 40 requests would pull out of the same per user rate limit bucket. That means that if this endpoint has a user rate limit of 1,000 requests per 24 hours, then this user would be able to like 960 more Tweets within that 24 hour period of time across all Twitter and third-party apps. 


HTTP headers and response codes

Use the HTTP headers in order to understand where the application is at for a given rate limit, on the method that was just utilized.

Note that the HTTP headers are contextual. When using application-only authentication, they indicate the rate limit for the application context. When using user-based authentication, they indicate the rate limit for that user context.

  • x-rate-limit-limit: the rate limit ceiling for that given endpoint
  • x-rate-limit-remaining: the number of requests left for the 15-minute window
  • x-rate-limit-reset: the remaining window before the rate limit resets, in UTC epoch seconds
     

When an application exceeds the rate limit for a given Twitter API endpoint, the API will return a HTTP 429 “Too Many Requests” response code, and the following error will be returned in the response body:

{ "errors": [ { "code": 88, "message": "Rate limit exceeded" } ] } 

 

Recovering from a rate limit 429 errors

When these rate limits are exceeded, a 429 'Too many requests' error is returned from the endpoint.  As discussed below, when rate limit errors occur, a best practice is to examine HTTP headers that indicate when the limit resets and pause requests until then.  

When a "too many requests" or rate-limiting error occurs, the frequency of making requests needs to be slowed down. When a rate limit error is hit, the x-rate-limit-reset: HTTP header can be checked to learn when the rate-limiting will reset. 

Another common pattern is based on exponential backoff, where the time between requests starts off small (e.g. a few seconds), then doubled before each retry. This is continued until a request is successful, or some reasonable maximum time between requests is reached (e.g. a few minutes).  

Ideally, the client-side is self-aware of existing rate limits and can pause requests until the currently exceeded window expires. If you exceed a 15-minute limit, then waiting a minute or two before retrying makes sense.

Note that beyond these limits on the number of requests, the Standard Basic level of access provides up to 500,000 Tweets per month from the recent search and filtered stream endpoints. If you have exceeded the monthly limit on the number of Tweets, then it makes more sense for your app to raise a notification and know its enrollment day of the month and hold off requests until that day.  
 

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 filtered and sampled stream endpoints. 
 

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 filtered stream endpoint and filter with your search queries.
 

Denylist

If an application abuses the rate limits, it will be denied. Denied apps are unable to get a response from the Twitter API. If you or your application has been denied and you think there has been a mistake, you can use our Platform Support forms to request assistance. Please include the following information:

  1. Explain why you think your application was denied.
  2. If you are no longer being rate limited, describe in detail how you fixed the problem.

 

Twitter API v2 rate limits

v2 Standard Basic access

The following table lists the rate limits for the Twitter API v2 with Standard Basic access. These rate limits are also documented on each endpoint's API Reference page and also displayed on the developer dashboard.

Endpoint Requests per 15-minute window
  Per app Per user
Tweets lookup  300 900
Users lookup 300 900
Recent search * 450 180

Filtered stream * 
- Connecting

- Adding/deleting filters

- Listing filters


50

450

450

 

Sampled stream

- Connecting

 

50

 
Hide replies   50

 

*Recent search and filtered stream share a monthly Tweet cap limit of 500,000 Tweets. 

Was this document helpful?

Thank you

Thank you for the feedback. We’re really glad we could help!

Thank you for the feedback. How could we improve this document?

Thank you for the feedback. Your comments will help us improve our documents in the future.