Rate limits: Standard v1.1 (original) (raw)

Overview

Standard

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 v1.1 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.

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.