How to Get a Twitter/X API Key in 2026 (Step-by-Step)

By Sorsa Editorial

Updated June 14, 2026: re-verified the post-April-20 pay-per-use rates (owned reads at $0.001 per resource, URL posts at $0.20, and follow, like, and quote-post writes moved to Enterprise) and the console.x.com signup flow against X's official documentation, and refreshed the internal references in this guide.

That five-minute setup gets you a working key. The harder question is whether you need the official X API at all. If your project only reads public X data, pulling tweets, searching keywords, looking up profiles, or tracking followers, you can skip OAuth, credit top-ups, and per-resource billing entirely. Sorsa API, an alternative Twitter/X API provider, hands you a read-only key in about three minutes with no developer-account approval, a flat 20 requests per second on every plan, and flat per-request pricing that runs up to roughly 50x cheaper than the official API on read workloads. This guide covers both paths: the full official signup at console.x.com, and the read-only route that most data projects actually want.

If you have read older guides, you have probably seen references to a free developer tier, the $100 or $200 Basic plan, or a multi-day approval queue. None of that applies to new developers now. X replaced subscription tiers with pay-per-use pricing in early 2026 and removed the approval wait, then changed its rates again on April 20. The steps below reflect the current process.

Table of Contents

• What Is an X (Twitter) API Key?
• Do You Actually Need the Official X API?
• How to Get an Official X API Key (Step-by-Step)
• What the Official X API Costs in 2026
• The Faster Path: A Read-Only Twitter/X API Key in Three Minutes
• Keeping Your X API Keys Secure
• In Practice: A Migration Example
• FAQ
• Getting Started

What Is an X (Twitter) API Key?

An X (Twitter) API key is a credential that identifies your application to X's servers when it requests data or performs actions. The current X API issues a set of credentials per app: an API key and API key secret (together the consumer key pair), a bearer token for app-only read access, and access tokens for acting on behalf of a user account.

People use "API key" loosely to mean any of these. In practice they do different jobs. The API key and secret authenticate the application during an OAuth 1.0a signing process. The bearer token is self-contained and authenticates app-only requests to public data, which is why read-only projects rarely touch anything else. Access tokens (and the OAuth 2.0 Client ID and secret) come into play only when your app acts as a specific user, for example to post on someone's behalf.

The current version is X API v2. The older v1.1 is legacy and kept only for a few media and specialized endpoints, so new projects should target v2.

Do You Actually Need the Official X API?

You need the official X API only if you must write to the platform: posting, replying, sending direct messages, or managing a user's account. For read-only work, retrieving tweets, profiles, search results, follower lists, or mentions, a third-party read-only API covers the same public data with simpler authentication and lower cost, and is usually the faster choice.

The split is clean because the two jobs have genuinely different requirements:

Writes are the one place the official X API is irreplaceable. If you need to publish content or send DMs, you need an X developer account, full stop. There is no way around it, and any guide claiming otherwise is wrong.

Reads are the opposite story. If you are building a social listening dashboard, collecting data for research, monitoring brand mentions, or pulling follower graphs, the official API adds work and cost you do not need: OAuth setup, a credit balance to manage, and billing that charges for every single tweet and profile returned. A read-only alternative X API returns the same public objects through one key in a header, charges a flat rate per request rather than per item, and skips the developer-account queue. For data work, that is the better tool, and it is the one we built Sorsa to be. The official API is worth the overhead only when posting or DMs are part of the job.

How to Get an Official X API Key (Step-by-Step)

To get an official X API key, sign in at console.x.com with your X account, accept the Developer Agreement, create a project and an app, then open the app's Keys and Tokens page to copy your API key, API key secret, and bearer token. Approval is automatic for standard access, with no manual review.

This is the current flow as of June 2026. If you have seen guides pointing to developer.twitter.com or apps.twitter.com, those URLs are outdated. Everything now runs through the Developer Console at console.x.com.

Step 1: Create a developer account

Go to console.x.com and sign in with your regular X account. There is no separate developer login; your existing X account works.

You will accept the Developer Agreement and Policy, then fill in a short profile describing how you plan to use the API. Write something honest and specific, for example "tracking public mentions of your brand from a Python script," but do not overthink it. The description is not manually reviewed, and approval for standard access is automatic.

One edge case: if your X account has been flagged for spam or bot activity, onboarding can be blocked. That flag is separate from API access and behaves differently from the data-collection blocks an automated client can trigger. Use an established account with normal history and you will be fine.

Step 2: Create a project and app

From the console dashboard, create a project, then add an app inside it. Give the app a name (it must be unique across all X developer apps). The console generates your credentials as soon as the app exists.

Step 3: Save your credentials

This is the step people rush and regret. X generates several credentials, each with a distinct role:

Save everything the moment it appears. These values are shown once. Lose them and you must regenerate, which invalidates the previous set. Store them in a password manager, a .env file, or a secrets vault, not in a chat message or a note.

For most people reading this guide, the bearer token is the credential that matters. It handles read-only access to public data with no OAuth signing: drop it into an Authorization header and go.

Step 4: Configure app permissions

In your app settings, open User Authentication Settings. Three permission levels are available:

• Read: can only read public data
• Read and Write: can read, and can post, like, and follow
• Read, Write, and Direct Messages: full access including DMs

If you only need to read using a bearer token, you can skip this step. Permission configuration matters only for OAuth user-context actions.

One detail that trips developers up: if you change permissions after generating your access token and secret, you must regenerate those tokens. The old ones keep the old scope. This is the most common cause of 403 Forbidden errors when someone tries to post after upgrading from read-only permissions.

Step 5: Make your first API call

Test your bearer token with a simple user lookup:

curl "https://api.x.com/2/users/by/username/elonmusk" \
  -H "Authorization: Bearer $BEARER_TOKEN"

A JSON response with user data means your credentials work. A 401 Unauthorized usually means the token was copied with an extra space or a missing character.

What the Official X API Costs in 2026

The official X API uses pay-per-use pricing in 2026: there are no subscription tiers for new developers, and you load credits that are charged per resource fetched. Reading a post costs about $0.005 and reading a user profile about $0.010, so a single search returning 20 tweets with author data costs roughly $0.30. Pay-per-use accounts are capped at 2 million post reads per month.

X moved to pay-per-use in February 2026, then restructured rates on April 20. Here is where the per-resource pricing stands now:

The phrase to watch is per resource, not per request. If a search returns 20 tweets, that is 20 x $0.005 = $0.10, and if you also pull each author profile, add 20 x $0.010 = $0.20. One search call with author data costs about $0.30. Repeated reads of the same resource within 24 hours are charged only once, which softens the math for polling the same objects, but the per-item model adds up fast at volume. Above the 2 million post-read monthly cap, the only option is an Enterprise contract negotiated with X, historically starting around $42,000 per month.

This is where a flat-rate model pulls ahead for data work. Instead of paying per item, a read-only provider charges one request per call regardless of how many objects come back, and includes the author profile inside each tweet at no extra cost. The side-by-side:

A concrete example: that single search call returning 20 tweets with author profiles costs about $0.30 on the official API and $0.00199 on Sorsa's Pro plan, roughly 150x less for the same data. Batched, the gap holds: 100 tweets by ID with authors cost about $1.50 on the official API (100 post reads plus 100 user reads) versus one $0.00199 request on Sorsa. For the full breakdown with real-world monthly scenarios, see our X API pricing breakdown for 2026. The honest summary: pay-per-use is genuinely cheap below roughly 10,000 post reads a month, and flat-rate wins decisively above that.

The Faster Path: A Read-Only Twitter/X API Key in Three Minutes

A read-only Twitter/X API needs only a single API key in a request header, with no OAuth, no token juggling, and no per-resource billing. If your project only reads public X data, searching tweets, pulling profiles, tracking mentions, analyzing followers, this is all the setup you need.

Sorsa is a managed REST API that provides read-only access to public X data through 40 endpoints across 8 categories: user profiles, tweets, search, follower and following graphs, communities, lists, trends, and verification checks. Here is the setup:

1. Open the Sorsa dashboard and register with Google or any available provider. No X account is required.

2. Pick a plan (Starter at $49 per month for 10,000 requests, Pro at $199 for 100,000, or Enterprise at $899 for 500,000) and complete payment.

3. Copy your API key from the dashboard. You are ready to make calls.

Test it with a profile lookup:

curl --request GET \
  --url 'https://api.sorsa.io/v3/info?username=elonmusk' \
  --header 'ApiKey: YOUR_API_KEY'

Or in Python:

import requests

response = requests.get(
    "https://api.sorsa.io/v3/info",
    params={"username": "elonmusk"},
    headers={"ApiKey": "YOUR_API_KEY"},
)

data = response.json()
print(data["display_name"])     # Elon Musk
print(data["followers_count"])  # follower count

Two design choices keep the cost low. The full author profile ships inside every tweet response at no extra charge, so you are not billed twice to know who posted. And batch endpoints count as one request: /info-batch takes up to 100 profiles and /tweet-info-bulk takes up to 100 tweets, each a single call against your quota. If you want to try endpoints before committing, the API Playground runs them in the browser with no key and no setup, and the API reference documents every parameter and response field.

Keeping Your X API Keys Secure

These practices apply whether you use the official X API, a read-only API, or any other service.

Use environment variables. Never hardcode keys in source. Load them at runtime from a .env file:

X_BEARER_TOKEN=your_bearer_token_here
SORSA_API_KEY=your_sorsa_key_here

Add .env to .gitignore. Credentials pushed to a public repository get scraped within minutes. This is not hypothetical: across the migrations we have handled, we have watched keys committed by mistake get abused before the developer noticed, and the cleanup is painful.

Rotate keys periodically. Both the X Developer Console and the Sorsa dashboard let you regenerate keys. Do it every few months, or immediately if a key may have leaked.

Use the least privilege your app needs. On the official API, do not enable Read, Write, and DM if you only read. On a read-only API the scope question disappears, since there is no write access to grant, but limiting who on your team holds the key still matters.

In Practice: A Migration Example

A roughly 10-person analytics team came to us mid-migration after their official X API bill outgrew what their dashboard product could absorb. Almost all of their spend was read traffic: thousands of profile and tweet reads a day, each billed per resource, with author data billed again on top. Moving the read workload to a flat per-request model cut that line item by roughly 30 to 50x, since the same calls that cost dollars per thousand on the official API land inside a single flat-rate request, author profiles included. They kept a minimal official app for the occasional automated post, and ran everything else through the read-only key. That hybrid shape, official API for writes, flat-rate API for reads, is the most cost-effective architecture we see for mixed pipelines. For a step-by-step walkthrough of moving a project across, see the migration guide.

FAQ

Is the X (Twitter) API free in 2026?

No. X discontinued its free tier for new developers and moved to pay-per-use pricing in early 2026. New accounts must load credits before making calls, with no free read allowance, and legacy free-tier users were migrated to pay-per-use with a one-time credit. For zero-cost access to public X data, free third-party tools like the Sorsa API Playground let you query endpoints in the browser without a key, or you can use open-source scrapers within their limits.

What is the difference between an X API key, API secret, and bearer token?

An X API key (the consumer key) identifies your application, and the API key secret signs OAuth 1.0a requests alongside it. A bearer token is a standalone credential for app-only read access to public data: drop it into an Authorization header and it works on its own. For read-only projects, the bearer token is usually the only credential you need; the access token and secret are required only to act as a specific user.

How long does X API approval take in 2026?

Approval for standard X API access is instant. You sign in at console.x.com, accept the Developer Agreement, create an app, and receive credentials in under two minutes, with no manual review queue. The main exception is the Ads API, which still requires separate approval and can take longer. Accounts flagged for spam or bot activity may be blocked during signup.

What happened to the X API free, Basic, and Pro plans?

X retired the free tier and closed the $100-to-$200 Basic and $5,000 Pro subscriptions to new signups when it launched pay-per-use pricing in early 2026. Existing subscribers can keep their legacy plans, but new developers can only choose pay-per-use or Enterprise. For a full timeline and current rates, see the Sorsa X API pricing breakdown.

Can I get Twitter/X data without an X developer account?

Yes. For read-only access to public Twitter/X data, an alternative API like Sorsa needs no X account: you register with an email or Google login, copy a single API key, and start querying profiles, tweets, search, followers, and mentions. An X developer account is required only for the official API, which is the only way to post or send DMs.

How do developers read Twitter/X data affordably in 2026?

Developers reading Twitter/X data at any real volume in 2026 typically use a flat-rate alternative rather than the official pay-per-use API, which bills per resource fetched. Sorsa charges one request per call regardless of how many items return, so 1,000 post reads cost about $0.10 on its Pro plan versus roughly $5.00 on the official API, with author profiles included free.

Why was my X API developer signup blocked?

Outright blocks are rare in 2026 because X API onboarding is automated. If you cannot complete signup, the usual causes are an X account flagged for spam or bot activity, an account too new or with no history, or access from a restricted region. Automation flags on your main account are a separate issue from API access. Use an established account and try again.

Getting Started

Two paths, depending on what you need.

To read public Twitter/X data: create a Sorsa account, pick a plan, and copy your key, or test endpoints first in the free Playground with no setup. You get 40 endpoints across user profiles, tweets, search, followers, lists, communities, and trends, a flat 20 requests per second on every plan, and a 3-minute setup with no approval queue. The quickstart gets you from key to first response in a few lines.

To post, like, follow, or send DMs: sign in at console.x.com, create your app, and budget for pay-per-use credits at $0.005 to $0.20 per operation depending on the action.

Building a read-heavy app that also needs to post? Run reads through a flat-rate provider and keep a minimal official app for writes. It is the cheapest way to cover both.

Reviewed by Keksich, founder of Sorsa, marketer and X API researcher.

This guide draws on hands-on work building and operating Sorsa's alternative Twitter/X API, the live endpoints we test against, and primary sources checked while writing. We reconfirmed the current signup flow and the post-April-20 rates against X's official About the X API documentation and its pay-per-use launch announcement, and cross-checked our own figures against the Sorsa API documentation and pricing. Where this article compares the official API and a flat-rate alternative, the numbers for both are stated in full, including our genuine limit: Sorsa is read-only. Verified June 14, 2026. Questions or corrections: contact us.