Twitter Code Number

[Kena Sugrue]

NoteIf your account has SMS text message two-factor authentication turned on (and when it is the only two-factor option turned on) and you're still logged in, you can remove your phone from your Mobile settings on X.com. Click Delete my phone and two-factor authentication will be automatically turned off for your account.

A backup code is automatically generated for you when you turn on two-factor authentication through your iOS or Android X app. You can also generate a backup code on twitter.com. Write down, print or take a screenshot of this backup code. In the event that you lose your mobile device or change your phone number, you can use this backup code to log in to your account. Backup codes are not the same as temporary passwords.

Note: You can generate up to five active backup codes at any given time. Be sure to use the codes in the order in which you generated them; using a code out of order will invalidate all previously generated codes.

Note: If you add a security key for additional two-factor authentication protection, we no longer require using another backup method for more protection. Security keys can be used as your sole authentication method, without any other methods turned on.

When you log in to your account on twitter.com or on another device using X for iOS, X for Android, or mobile.twitter.com, a push notification may be sent to your phone. Open the push notification to approve the login request. Once you approve, you will be immediately logged in to your account on twitter.com.

You may also receive a login code via SMS text message. You can opt into this by clicking request a code sent to your phone via text message when you log in to your account on twitter.com.

Note: You can also approve or deny your login requests from within the app by tapping Security, then tapping Login Requests. Pull down on the list to refresh for new requests. Requests will appear on this screen even if you did not receive a push notification.

Note: If you add a security key for additional two-factor authentication protection, we no longer require using another backup method for more protection. Security keys can be used as your sole authentication method, without any other methods turned on.

You may also receive a login code via SMS text message. You can opt into this by clicking request a code sent to your phone via text message when you log in to your account on twitter.com.

Note: You can also approve or deny your login requests from within the app by tapping Security, then tapping Login Requests. Pull down on the list to refresh for new requests. Requests will appear on this screen even if you did not receive a push notification.

After you enable two-factor authentication for your account, you'll need to use a temporary password to log in to X on other devices or applications that require you to enter your X password; you will not be able to log in using your usual username and password combination. If we detect you will need a temporary password to log in, we will send one via SMS text message to your phone. Alternatively, you can generate your own temporary password.

This page describes how characters are treated when composing Tweets and across the Twitter API. For more information on the implementation, Twitter provides an Open Source twitter-text library that can be found on GitHub.

Twitter began as an SMS text-based service. This limited the original Tweet length to 140 characters (which was partly driven by the 160 character limit of SMS, with 20 characters reserved for commands and usernames). Over time as Twitter evolved, the maximum Tweet length grew to 280 characters - still short and brief, but enabling more expression.

We refer to whether a glyph counts as one or more characters as its weight. The exact definition of which characters have weights greater than one character is found in the configuration file for the twitter-text Tweet parsing library.

The current version of the configuration file defines a default two-character weight and four ranges of Unicode code points that are weighted differently. Currently code points in these ranges are all counted as a single character.

Emoji supported by twemoji always count as two characters, regardless of combining modifiers. This includes emoji which have been modified by Fitzpatrick skin tone or gender modifiers, even if they are composed of significantly more Unicode code points. Emoji weight is defined by a regular expression in twitter-text that looks for sequences of standard emoji combined with one or more Unicode Zero Width Joiners (U+200D).

Replies: @names that auto-populate at the start of a reply Tweet will not count towards the character limit. New non-reply Tweets starting with a @mention will count, as will @mentions added explicitly by the user in the body of the Tweet.

Twitter counts the number of code points in the text, rather than UTF-8 bytes. The 0xC3 0xA9 from the caf example is one code point (U+00E9) that is encoded as two bytes in UTF-8, whereas 0x65 0xCC 0x81 is two code points encoded as three bytes.

Every day many thousands of developers make requests to the X 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.

The following table lists the rate limits for the X API v2 Free access. These rate limits are also documented on each endpoint's API Reference page and also displayed in the developer portal's products section.

The following table lists the rate limits for the X API v2 Basic access. These rate limits are also documented on each endpoint's API Reference page and also displayed in the developer portal's products section.

The following table lists the rate limits for the X API v2 Pro access. These rate limits are also documented on each endpoint's API Reference page and also displayed in the developer portal's products section.

Users' rate limits are shared across all Apps that they have authorized. For example, if a specific user likes 20 Posts using one developer App and likes 20 Posts 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 Posts within that 24 hour period of time across all X and third-party apps.

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.

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 (for example, 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 (for example, 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 Posts per month from the recent search and filtered stream endpoints. If you have exceeded the monthly limit on the number of Posts, 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.

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.

If your site keeps track of many X users (for example, fetching their current status or statistics about their X usage), consider only requesting data for users who have recently signed into your site.

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.

3a8082e126