Twitter (X) Access Token: The 4 Credential Types, Which Endpoints Need Which, and How to Get and Validate Each

X's authentication overview lists four methods: OAuth 1.0a User Context, App only, Basic authentication (enterprise APIs only) and OAuth 2.0 Authorization Code Flow with PKCE. The developer-apps page describes the credentials each App holds under its Keys and tokens tab: the API Key and Secret ("Authenticate with OAuth 1.0a. Used to sign requests or generate user tokens."), the Bearer Token ("App-only authentication for public data endpoints."), the Access Token and Secret ("Make requests on behalf of your own account (OAuth 1.0a).") and the Client ID and Secret ("Authenticate with OAuth 2.0. Used for authorization code flow."). The OAuth 2.0 user access token is not stored in the console at all; your code receives it from the token endpoint after a user authorizes.

The consumer keys are not an access token. This is the most common confusion in the forum threads that rank for this query. The API Key and Secret identify your App. On their own they let you do exactly two things: sign an OAuth 1.0a request (always together with a user's Access Token and Secret) and mint the App's bearer token by presenting them as HTTP Basic credentials to POST https://api.x.com/oauth2/token. If a library asks for "consumer key" or "client key", it means these. If a 401 comes back from a call signed with only the consumer keys, nothing is broken; you have simply not supplied a token.

Where to find them (in words; the console changes too often for screenshots to stay honest). Sign in at the X Developer Console, open the Projects and Apps view, pick the App, and open its Keys and tokens tab. The tab has one block per credential type, each with a Regenerate (or Generate) button. Per the developer-apps page, each secret is "only shown once" when generated: copy it into your secret store immediately, because the next time you open the tab you will only be able to regenerate it, which invalidates the old value everywhere it is deployed.

Permission level is set on the App, not the token. Under User authentication settings you choose Read only, Read and write, or Read, write and Direct Messages for OAuth 1.0a, and confidential or public client type for OAuth 2.0. The same page states that "Changing permissions requires users to re-authorize your app to get new tokens with the updated scope." In practice: if you flip an App from read-only to read-and-write, regenerate your own Access Token and Secret and expect every other user's token to need a fresh authorization before writes succeed.

The bearer token is what most people mean by "twitter token" when they want to read public posts from a script. X's bearer-token page describes it as "a more secure point of entry for using the X APIs" and gives two ways to get it: copy it from the App's Keys and tokens page, or mint it yourself by sending the consumer keys as Basic auth to POST https://api.x.com/oauth2/token with grant_type=client_credentials. The response is {"token_type":"bearer","access_token":"AAAA..."}. The API reference adds a detail that explains a lot of confused issues: "Only one bearer token may exist outstanding for an application, and repeated requests to this method will yield the same already-existent token until it has been invalidated." So calling the token endpoint again does not rotate the token; POST https://api.x.com/oauth2/invalidate_token (or Regenerate in the console) does.

What it can and cannot do. It represents the App, not a person, so it works on endpoints that read public information and fails on anything that needs a user: posting, liking, following, muting, bookmarks, direct messages and GET /2/users/me. The census below counts 14 of 20 common endpoints as accepting it, and three of those (full-archive search, the filtered stream and its rules) accept nothing else. The pricing page's examples all use Authorization: Bearer $BEARER_TOKEN, and the pay-per-usage rate card is what you pay per resource it returns: $0.005 per post read, $0.010 per user read, $0.010 per follower or following read, capped at 3 million post reads a month before Enterprise.

Does it expire? The bearer-token page and the API reference do not state a lifetime; the only documented ways it stops working are invalidation and regeneration. Treat it as long-lived and rotate it on a schedule you choose. The curl session below mints one, uses it on two public reads against X's api.x.com/2/... paths, and revokes it.

This is the credential the phrase "access token" originally meant on Twitter, and it is still what GET /2/users/me, POST /2/tweets and every other user-context endpoint accept under the name UserToken. It is a pair: the Access Token (oauth_token) and the Access Token Secret (oauth_token_secret), issued to your App for one specific user, and used together with the consumer keys to sign each request with HMAC-SHA1. Per X's OAuth 1.0a guide, these tokens "do not expire but can be revoked by the user at any time"; the authentication FAQ adds that a token is also invalidated if X suspends the App, and that you should "assume a user's access token may become invalid at any time" and re-prompt for authorization when it does.

Your own account's pair is the easy case: in the App's Keys and tokens tab, generate the Access Token and Secret, and they are issued for the account that owns the developer account, at the App's current permission level. That is all a single-account bot or a personal analytics script needs.

Anyone else's pair comes from the 3-legged flow, which the docs lay out as three calls: POST oauth/request_token ("Create a request for a consumer application to obtain a request token."), GET oauth/authorize ("Have the user authenticate, and send the consumer application a request token."; oauth/authenticate is the variant that skips the approval screen for users who already authorized the App), and POST oauth/access_token ("Convert the request token into a usable access token."). The request token and secret are temporary; the result is the user's durable pair, which you store server-side against that user. Revocation from your side is POST oauth/invalidate_token.

Permission level is baked in at issue time. A pair issued while the App was read-only stays read-only even after you raise the App's permissions; regenerate your own pair and have other users re-authorize. This is the usual cause of a 403 on POST /2/tweets from an otherwise working token.

The newest credential is the one X's overview describes as letting you "authenticate on behalf of another account with greater control over an application's scope." It is a plain bearer string, sent as Authorization: Bearer <token> like the app-only token, but it represents a user and a specific set of scopes. The current scope list on docs.x.com has 24 entries: tweet.read, tweet.write, tweet.moderate.write, users.email, users.read, follows.read, follows.write, offline.access, space.read, mute.read, mute.write, like.read, like.write, list.read, list.write, block.read, block.write, bookmark.read, bookmark.write, dm.read, dm.write, media.write, broadcast.read and broadcast.write.

The flow in one paragraph (the full walkthrough with code is in our OAuth 2.0 user-context setup guide, linked below): your App's Client ID (and, for confidential clients, Client Secret) come from Keys and tokens; you send the user to https://x.com/i/oauth2/authorize with response_type=code, client_id, redirect_uri, scope, state, code_challenge and code_challenge_method; the user approves; you exchange the returned code plus your code_verifier at POST https://api.x.com/2/oauth2/token with grant_type=authorization_code. Public clients (browser and mobile) send client_id in the body; confidential clients send the Client ID and Secret as Basic auth.

Lifetime, quoted: "By default, the access token you create through the Authorization Code Flow with PKCE will only stay valid for two hours unless you've used the offline.access scope." With that scope, "an OAuth 2.0 refresh token will be issued", and you exchange it at the same token endpoint with grant_type=refresh_token to get a new access token without prompting the user. The pages we read do not state how long a refresh token itself lives or whether each one is single-use, so design for both: store whatever refresh token the latest response returns, and handle a failed refresh by sending the user back through authorization.

Revocation is POST https://api.x.com/2/oauth2/revoke with token and client_id. Users can also remove the App from their account settings, after which both the access and refresh tokens stop working with a 401.

The question behind most "twitter access token" searches is really "which of these do I need for the call I am about to make". X answers it per endpoint: every reference page carries a security block listing some subset of BearerToken (app-only), UserToken (OAuth 1.0a user context) and OAuth2UserToken with its required scopes, and the v2 authentication mapping guide collects the same information in one table. We read both this session and tallied 20 endpoints a typical developer touches first. The chart and table are that tally; the source for each row is the mapping guide, except GET /2/users/me, where the endpoint's own reference page lists only the two user-token schemes (an App has no "me", so the mapping guide's summary row for it is misleading).

Reading the tally. 11 of the 20 accept all three token kinds; these are the public reads (lookups, timelines, recent search, followers, likes, list posts), and for them the bearer token is the simplest choice because it involves no user and never expires on a clock. 3 accept only the bearer token: full-archive search, the filtered stream and the stream-rules endpoint, which is why a user token alone cannot read the stream. 6 accept only user tokens: every write in the list, the muting list, and GET /2/users/me. Across the 20, OAuth 1.0a and OAuth 2.0 user tokens are accepted by exactly the same 17 endpoints, so between those two the choice is about expiry and scoping, not reach. The + in the last column means the scope is required on top of tweet.read users.read.

Rate limits also depend on the credential. The authorization-code page notes that for post and user lookup with OAuth 2.0 the per-App limit was raised "from 300 to 900 requests per 15 minutes"; app-only and user-context calls draw from different buckets, which is one reason production code often holds both a bearer token and a user token and picks per call.

User tokens: call GET /2/users/me. Its reference page lists OAuth2UserToken (scopes users.read, tweet.read) and UserToken as the accepted schemes, and a success returns data.id, data.name and data.username for the account the token represents. It is the one endpoint whose only purpose is to tell you whose token you are holding, which makes it the natural health check after a refresh or at process start. Bearer tokens have no "me", so validate them with the smallest public read you already use, for example GET /2/users/by/username/:username; a 200 proves the token is live.

Reading the failure codes. A 401 (Unauthorized) means X could not authenticate the request at all: an OAuth 2.0 user token older than two hours, a token the user revoked, a bearer token that was regenerated elsewhere, an OAuth 1.0a signature built with the wrong secret, or a malformed header. A 403 (Forbidden) means the token authenticated but is not allowed to do this: an OAuth 1.0a pair issued at a lower permission level than the call needs, an OAuth 2.0 token missing a scope, or an App whose access level does not include the endpoint. The split matters operationally: on 401 refresh or re-authorize, on 403 fix the App's permissions or scopes and re-issue, because retrying the same token will never succeed.

Storage. All four credentials are bearer secrets in the practical sense: whoever holds the string holds the access. Keep them in environment variables or a secret manager, never in source, notebooks, build logs or client-side JavaScript. The console shows each secret once; if you lose it, regenerate rather than hunt. Public-client OAuth 2.0 apps (browser, mobile) should hold only the Client ID, which is why PKCE exists. Store refresh tokens encrypted at rest and replace the stored value with whatever the latest refresh response returns.

Rotation. Bearer: POST oauth2/invalidate_token, then mint again, then redeploy. OAuth 1.0a: Regenerate in the console for your own pair, oauth/invalidate_token for users' pairs. OAuth 2.0: POST /2/oauth2/revoke with token and client_id. Rotate on every suspected exposure (a pasted log, a public repository, a departed teammate) and on a calendar for the long-lived kinds. A secrets scanner in CI catches the most common leak, which is a consumer secret or bearer token committed in a config file.

The Python below is the whole validation story in three functions: check a user token, check a bearer token, refresh an OAuth 2.0 user token.

If what you need is public data (profiles, timelines, searches, follower lists) and not actions as a user, none of the four credentials above is required. twitterapi.io authenticates every read with a single API key in an X-API-Key header, created in the dashboard with no X developer account, no App, no OAuth flow and no token expiry to manage. To show what that looks like in practice rather than in a sentence, we made 20 reads for five organization accounts (@NASA, @github, @stripe, @Cloudflare and @mozilla), one call per account on each of four endpoints, and timed each call around the client.

What the numbers say. Every call returned HTTP 200 and the fields the documentation promises: 25 profile fields (id, userName, followers, statusesCount, createdAt, isBlueVerified and so on), 30 fields per post (id, text, createdAt, likeCount, viewCount, author and the rest), 20 per follower record. The slowest single call took 3.09 s and the whole study 41.6 s of wall-clock, including the client-side pause that keeps our collector under its rate cap. The cost column uses the published twitterapi.io rate card: 18 credits per profile ($0.18 per 1,000), 15 credits per post returned ($0.15 per 1,000; a 15-credit minimum applies when a search returns nothing), and 1 to 3 credits per follower returned depending on the page tier, at $1 per 100,000 credits. The last column is the official pay-per-usage card from docs.x.com: $0.005 per post read, $0.010 per user read and $0.010 per follower read, so the same 1,000 follower records that cost $0.01 to $0.03 here cost $10.00 there, and 1,000 posts cost $0.15 here against $5.00, about 33x.

Credential arithmetic. The official bearer path needs an approved developer account, an App, the API Key and Secret, and one token call; the OAuth 1.0a path needs those keys plus a 3-legged exchange per user; the OAuth 2.0 path needs a Client ID, optionally a Client Secret, a PKCE round trip, and a refresh every two hours. The key-only path needs one string and zero round trips, and the endpoints answer with the same shape whether you ask about one account or a thousand. Rate limits on twitterapi.io are per account rather than per token kind: 0.2 requests a second before the first payment and 20 once paid, with higher tiers on the Scale and Business plans. New accounts that pass the automatic bot check get up to $1 of free credits (at most 100,000; one per person or network, expiring after 31 days), enough to repeat this study about 16 times; purchased credits never expire.

Writes are a separate, authenticated product. Posting, liking, following or sending a DM through twitterapi.io runs through a logged-in session: one /twitter/user_login_v2 login ($0.10, with a proxy you supply) returns login_cookies, and each subsequent action such as /twitter/create_tweet_v2 or /twitter/follow_user_v2 is $0.002 per HTTP 200 call. Every such call acts as that account, so X can rate-limit, lock or suspend it; keep a human pace, expect the session to need a fresh login from time to time, and keep the account's own credentials as carefully as any token on this page. For reads, no X account is needed at all.

The runnable script at the end of this page is the key-only path end to end: profile, latest posts with cursor pagination, and a search, all with the one header.

Question: which of X's three token kinds does each commonly used v2 endpoint accept, and what does the key-only alternative return, how fast and at what cost, for the same kinds of reads.

Census method: we read docs.x.com's v2 authentication mapping guide and the reference pages for GET /2/users/me, GET /2/tweets/search/recent, GET /2/users/:id/followers and POST /2/tweets in 2026 and recorded, for 20 endpoints chosen as the ones a developer typically calls first (lookups, search, stream, timelines, followers, likes, lists, the five most common writes, mutes), whether each lists UserToken, BearerToken and OAuth2UserToken, with the scopes for the last. The source URL for each row is stored with the study. The 20 are a selection, not the whole surface: Spaces, bookmarks, direct messages, media upload and compliance endpoints are not counted.

Live sample: 20 requests through a rate-limited, read-only client against twitterapi.io, one per endpoint per account for /twitter/user/info, /twitter/user/last_tweets (1 page), /twitter/tweet/advanced_search (from:<account>, queryType=Latest, 1 page) and /twitter/user/followers (1 page), for @NASA, @github, @stripe, @Cloudflare and @mozilla. Wall-clock was measured around each client call and includes up to 0.2 s of the client's own spacing between requests. Costs are computed from the published rate cards, not read from an invoice.

What the sample cannot show: five accounts and one call per endpoint is a snapshot of latency from one network location, not a service-level figure; the official API's latency was not measured, only its price. Follower page tiers mean the follower cost is a range. The census reflects the documentation on the day it was read; X changes endpoint access levels, and the per-endpoint reference page is always the authority for a specific call.

Privacy: the five accounts are organizations. Follower pages list private individuals, so they were counted and their field names recorded, then discarded; only the organization profiles, timelines and from: search pages are kept, gzip-compressed, with the analysis script, results and the census table in the study folder.