Rate limits

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. 


Standard API v1.1 rate limits per window

POST endpoints

The standard API rate limits described in this table refer to POST endpoints. These rate limits apply to the standard API endpoints only, does not apply to premium APIs.

Endpoint Rate limit window Rate limit per user Rate limit per app 
POST statuses/update
3 hours* 300* 300*
POST statuses/retweet/:id
3 hours* 300* 300*
POST favorites/create
24 hours 1000 1000
POST friendships/create
24 hours 400 1000
POST direct_messages/events/new
24 hours 1000 15000

 

Please note - The 300 per 3 hours is with the POST statuses/update and POST statuses/retweet/:id endpoints is a combined limit. You can only post 300 Tweets or Retweets during a 3 hour period. 

For example, if your Twitter app makes 200 requests to the POST statuses/update endpoint within a three hour period, your app will only be able to make 100 requests to the POST statuses/retweet/:id endpoint during that period. 
 

GET endpoints

The standard API rate limits described in this table refer to GET (read) endpoints. Note that endpoints not listed in the chart default to 15 requests per allotted user. All request windows are 15 minutes in length.  These rate limits apply to the standard API endpoints only, does not apply to premium APIs.

Endpoint Requests / window per user Requests / window per app
GET account/verify_credentials 75 0
GET application/rate_limit_status 180 180
GET favorites/list 75 75
GET followers/ids 15 15
GET followers/list 15 15
GET friends/ids 15 15
GET friends/list 15 15
GET friendships/show 180 15
GET geo/id/:place_id 75 0
GET help/configuration 15 15
GET help/languages 15 15
GET help/privacy 15 15
GET help/tos 15 15
GET lists/list 15 15
GET lists/members 900 75
GET lists/members/show 15 15
GET lists/memberships 75 75
GET lists/ownerships 15 15
GET lists/show 75 75
GET lists/statuses 900 900
GET lists/subscribers 180 15
GET lists/subscribers/show 15 15
GET lists/subscriptions 15 15
GET search/tweets 180 450
GET statuses/lookup 900 300
GET statuses/mentions_timeline 75 0
GET statuses/retweeters/ids 75 300
GET statuses/retweets_of_me 75 0
GET statuses/retweets/:id 75 300
GET statuses/show/:id 900 900
GET statuses/user_timeline 900 1500
GET trends/available 75 75
GET trends/closest 75 75
GET trends/place 75 75
GET users/lookup 900 300
GET users/search 900 0
GET users/show 900 900
GET users/suggestions 15 15
GET users/suggestions/:slug 15 15
GET users/suggestions/:slug/members 15 15
 

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.