How to get an X API key in 2026 (and what it now costs)

#Quick answer

To get an X API key in 2026, sign in at console.x.com with a verified X account, accept the Developer Agreement, create an app, then copy the keys from the app's Keys and Tokens tab. The catch is money, not setup: the self-serve free tier ended on February 6, 2026, and as of September 2026 both flat plans are gone too, so pay-per-use is the only self-serve route left.

Last updated: September 2026

#TL;DR

Getting an x api key is still a short flow, and this guide walks every screen. What changed is the pricing underneath it. X (formerly Twitter) retired its general free tier for new developers, made pay-per-use the default, and has since deprecated the two flat subscriptions that existing customers were sitting on. Most "how to get a free API key" posts still describe the 2023 flow and are simply out of date. Below is the current console.x.com process, the four credentials it hands you, X's own published rate card, the billing rule that quietly halves most bills, and an honest note on when the API is worth it versus a browser-based tool that never touches it.

#How to get an X API key: the current steps

X moved the developer portal to console.x.com. Old developer.twitter.com links still redirect there. Here is the flow that works in 2026, per X's own getting-access docs (docs.x.com, accessed 2026-09-15):

1. Sign in with a qualifying X account. You need a standard account with a verified email and a verified phone number. Accounts missing either get blocked before they reach the console.
2. Accept the Developer Agreement and Policy. X shows this on first entry. You cannot create anything until you accept it, and it is the document that governs what your key is allowed to do.
3. Describe your use case. X asks what you are building. Write a real, specific answer of at least a couple hundred characters ("a personal analytics dashboard that reads my own post metrics" beats "testing"). Vague answers slow approval.
4. Create an app. The app is the object that issues keys. Each app carries its own credential set, so keep a separate app per project rather than sharing one key across three things you might want to revoke independently.
5. Open Keys and Tokens and save everything. X's docs are blunt about this: "Credentials are only displayed once. Store them in a password manager or secure vault." If you lose a secret you regenerate it, which instantly invalidates anything still using the old value.
6. Enable billing and load credits. This is the step that did not exist before 2026. Until the project is approved and billing is on, your calls fail rather than bill.

That is the whole flow. The friction is not the clicks. It is deciding whether to pay for what happens after.

#What credentials you actually get

An X app issues four distinct credential types, and mixing them up is the most common setup mistake:

If you only want to read public posts, the Bearer Token is enough. If you want to post as yourself, you need the Access Token and Secret. If you are building something other people log into, you need the OAuth 2.0 client credentials. Store all of them in environment variables. Never paste a secret into client-side code or a public repo, and never into a repo you plan to open source later. For a worked example of calling endpoints once you hold keys, our guide to scraping X with Python covers what the paid and unofficial routes each look like in practice.

#The part most guides get wrong: the free tier is gone, and so are Basic and Pro

This is where stale articles mislead people, and the picture got worse during 2026, not better.

On February 6, 2026, X replaced its tiered model and made pay-per-use the default for new developers, discontinuing the general self-serve free tier. That much has been widely reported. What most pages have not caught up with is the second half:

• Legacy Basic ($200/month) is gone. Existing Basic subscribers were moved onto pay-per-use during 2026 (X Developers announcement, accessed 2026-09-15).
• Legacy Pro ($5,000/month) is gone too. X announced on August 14, 2026 that Pro is deprecated, with every remaining subscriber migrating automatically at their own cutover date (X Developers announcement).

So the honest 2026 answer to "which tier should I pick" is that there is no tier to pick. Self-serve means pay-per-use. Above its caps, the only step up is an Enterprise contract, which is a sales conversation, not a checkout button. If a comparison table still shows you a four-column Free / Basic / Pro / Enterprise grid, it is describing a product that no longer exists.

One more thing worth checking yourself rather than trusting an article: X's pricing page publishes no free tier and no starter credit as of 2026-09-15. You will find forum threads about promotional vouchers from the pay-per-use beta period. Treat those as historical unless you see the credit land in your own console.

#What the X API costs in 2026: the real rate card

Under pay-per-use you buy credits in the console and get billed per resource touched. These are X's own published prices, not a third-party estimate (docs.x.com pricing, accessed 2026-09-15):

Three things matter here, and only one of them shows up in other guides.

Writes cost more than reads, and links cost 13x a plain post. A link-heavy posting bot is the single most expensive thing you can build on this API. Forty linked posts a day is $8 a day, or roughly $240 a month, for posting alone.

Owned reads are a tenth of the price of public reads. Pulling your own posts, followers, and bookmarks is billed at $0.001, not $0.005 or $0.010. If you are building a personal analytics dashboard, structure it around owned-read endpoints and your bill barely registers.

The cap is 3 million post reads per monthly cycle, not 2 million. Plenty of pages still quote the older figure. Past the cap, Enterprise is the only route up.

#The billing rule that halves most bills

Buried in X's pricing docs is the detail that changes how you should write the code: the same resource requested more than once inside a 24-hour UTC window is charged only once (docs.x.com pricing, accessed 2026-09-15).

That deduplication window rewards a specific architecture. If your job polls the same 500 posts every hour to watch engagement climb, you are not paying 12,000 reads a day. You are paying 500, because you keep hitting the same resource IDs inside the same UTC day. Where costs actually explode is breadth: a crawler that discovers new post IDs on every pass pays full freight on every one of them.

Two practical consequences. Align any batch job to the UTC day boundary rather than local midnight, or a single run straddling 00:00 UTC bills twice. And if you are re-reading a known set, do it inside one UTC day rather than spreading it across two.

X also gives you two safety rails in the console worth turning on before your first real run: a spending limit per billing cycle, and auto-recharge, which is capped at one top-up per five-minute window and pauses when the balance hits zero. Set the spending limit first. A loop bug with auto-recharge on and no ceiling is the expensive version of this mistake.

There is a small rebate too: X returns up to 20% of your API spend as xAI API credits, tiered from 10% back at $200 cumulative spend to 20% at $1,000. Useful if you already build on xAI, irrelevant otherwise.

#Rate limits are a separate thing from price

A common mix-up: paying more does not buy you unlimited request throughput. Price and rate limits are two different systems.

Rate limits are per endpoint and measured in 15-minute windows (docs.x.com rate limits, accessed 2026-09-15). Lookup endpoints sit around 900 requests per 15 minutes at the app level; posting is far tighter, around 200 requests per 15 minutes at the user level. Your credits control how much data you may pull in a month. The rate limiter controls how fast.

Design for both. A job that needs 100,000 reads is affordable at $500 under the rate card, but if it runs against an endpoint capped at 900 requests per 15 minutes you also need to plan for how many hours it takes, and handle the 429 responses in between. Check the limit on the specific endpoints you call before you size anything, because they vary widely.

#When to skip the API entirely

Here is the honest trade-off. The API is the sanctioned route: X publishes the rules, and if you follow them your access is official. But it now costs money on the first call, it caps your reads, and X restricted programmatic replies and engagement actions on self-serve tiers during 2026. If your goal is scheduling, threading, or replying rather than building a data product, you may be paying a data-pipeline price for a publishing job.

A browser-session tool takes the other path: it acts through your own logged-in session instead of buying API credits. It drives the same x.com you already use, so it never touches a developer key, a credit balance, or a post-read cap. That is the model behind X-Autopilot and similar local tools.

Be clear-eyed about it: automating engagement through a browser is a gray area under X's automation rules, not a sanctioned path the way the API is. We will not claim it is risk-free or ToS-compliant, because it is neither. What a local, session-based tool does offer over shared cloud services is a smaller detection surface: your own residential IP and browser, with the session cookie staying on your machine rather than sitting in a vendor's cloud. That is lower relative risk, not the absence of risk. If you want the fully sanctioned path, use the API and budget for it. If you want to publish and grow without a metered developer bill, weigh a browser tool against your own risk tolerance.

Our roundup of the best X API alternatives and the best automation tools for real growth compare both routes side by side, and the X API cost and access guide goes deeper on how the tiers got here.

#The short version

Creating an x api key in 2026 is easy: console.x.com, verified account, app, copy the keys, enable billing. The decision is economic, not technical.

Scope your call volume against the rate card before you write a line of code. Favour owned reads where you can, cache aggressively inside the UTC day so deduplication works for you, set a spending limit, and check the rate limit on every endpoint you plan to hammer. If you are building a data or analytics product, the API is the right and sanctioned tool, and the numbers above make it plannable. If you just want to post and grow, a session-based browser tool may do the job without a developer bill, as long as you accept that it trades sanctioned status for convenience.