Rate limits


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. 

Table of contents


Twitter API v2 rate limits

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

Resource Endpoint Requests per 15-minute window unless otherwise stated
Per App Per user
Tweets Tweet lookup 300 900
- User Tweet timeline
- User mention timeline


Search Tweets
- Recent search
- Full-archive search


Full-archive also has a 1 request / 1 second limit

Tweet counts
- Recent Tweet counts
- Full-archive Tweet counts

Filtered stream
- Connecting
- Adding/deleting filters
- Listing filters

Sampled stream 50  
Retweets lookup 75 75
Manage Retweets **
- Retweet a Tweet
- Undo a Retweet


Likes lookup
- Tweets liked by a user
- Users who have liked a Tweet


Manage Likes **
- Like a Tweet
- Unlike a Tweet
Hide replies 50  
Users User lookup 300 900
Follows lookup 15 15
Manage follows **
- Follow a user
- Unfollow a user
Blocks lookup   15
Manage blocks
- Block a user
- Unblock a user
Mutes lookup   15
Manage mutes
- Mute a user
- Unmute a user
Lists Manage Lists
- Create a List
- Delete a List
- Update a List
Manage List members
- Add a member
- Remove a member
Manage List follows
- Follow a List
- Unfollow a List
Manage pinned Lists
- Pin a List
- Unpin a List
Spaces Spaces lookup 300  
Search Spaces 300  
Compliance Batch compliance
- Create a job
- Get jobs
- Get job by ID



** These POST and DELETE endpoints also have additional limits:


Manage Retweets

Create Retweet 300 successful requests per 3-hour window per user
Delete Retweet 1000 successful requests per 24-hour window per user

Manage Likes

Like a Tweet 1000 successful requests per 24-hour window per user
(This limit is shared by both the Like a Tweet and delete Like endpoints)
Delete Like

Manage follows

Follow a user 400 successful requests per 24-hour window per user
1000 successful requests per 24-hours per App
Unfollow a user 500 successful requests per 24-hours per App


Please note

In addition to rate limits, we also limit the number of Tweets that any Project can retrieve from certain endpoints in a given month, based on your product track and access level. To learn more, please visit our section on Tweet caps.

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: App rate limit
    All Twitter API v2 endpoints except for hide replies 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: User rate limit
    Several v2 endpoints 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. For example, if a specific user likes 20 Tweets using one developer App and likes 20 Tweets on a separate developer App within a 15 minute time period, 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 15 minutes, 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

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. 


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.


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.