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 a project and 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, so new developers now pay per call under pay-per-use.

Last updated: August 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 and made pay-per-use the default, so every read and write now carries a per-call charge. Most "how to get a free X API key" posts you will find 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, the 2026 cost model, 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

The developer portal moved from developer.twitter.com to console.x.com. If you land on the old domain, you get redirected. Here is the flow that actually works in 2026:

1. Sign in with a qualifying X account. You need a standard X 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 a project, then an app. The app is the object that issues keys. One project can hold apps, and each app has its own credential set.
5. Open Keys and Tokens and save everything. X displays secrets once. Copy them immediately into a password manager or environment file. If you lose a secret you have to regenerate it, which invalidates anything using the old value.

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. Per X's own developer docs, they are:

| Credential | What it is for | |---|---| | API Key and Secret | Identify your app and sign OAuth 1.0a requests. The "consumer" keys. | | Bearer Token | App-only authentication for reading public data. No user context. | | Access Token and Secret | Act on behalf of your own account (post, like, follow as you). | | OAuth 2.0 Client ID and Secret | User-context flows where other people authorize your app. |

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. For a worked example of calling the endpoints once you have keys, see our guide on how to use the X API with Python.

#The part most guides get wrong: there is no free tier anymore

This is where stale articles mislead people. On February 6, 2026, X replaced its old tiered model and made pay-per-use the default for new developers. As part of that change, the general free tier was discontinued for new signups, and the flat Basic and Pro subscriptions were closed to new customers (they remain only for accounts that already subscribed).

So if a 2025 tutorial promises "1,500 free posts a month," that offer no longer exists for a new key. X has said it may still grant free access to public-good utility apps on a case-by-case basis, but you cannot self-serve it. For most people, the first meaningful API call now costs money.

For a fuller breakdown of what each historical tier included and how access levels evolved, our X API cost and access guide and the primer on what the X API is and how to use it go deeper.

#What the X API costs in 2026

Under pay-per-use you buy credits in the console and get billed per resource touched. Independent reporting of the early-2026 rates (verify the live numbers in your console before you build, since X adjusts them):

| Action | Reported rate | |---|---| | Read a post | ~$0.005 each | | Read a user | ~$0.010 each | | Create a post | ~$0.015 each | | Create a post with a link | ~$0.20 each | | Monthly post-read cap | ~2,000,000 |

Two things matter here. First, writes cost more than reads, and links cost a lot more - a link-heavy posting bot is the most expensive thing you can build. Second, there is a hard monthly read cap; past it, the only way up is Enterprise, which jumps into five figures a month. Legacy Basic ran $200/month and Pro $5,000/month, but again, those are closed to new signups.

Do the arithmetic for your own use before committing. A dashboard that reads your metrics a few hundred times a day is cheap. A tool that reads timelines continuously, or posts dozens of linked tweets daily, adds up quickly.

#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, 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.

The alternative is a tool that acts through your own logged-in browser session instead of buying API credits - it drives the same x.com you use, so it never touches a developer key. That is the model behind X-Autopilot and similar local tools, and it sidesteps API billing and read caps completely.

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 zero. 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 compares both routes side by side.

#The short version

Creating an x api key in 2026 is easy - console.x.com, verified account, project, app, copy the keys. The decision is economic, not technical. New keys are pay-per-use, reads are capped, and writes with links are expensive, so scope your call volume first. If you are building a data or analytics product, the API is the right, sanctioned tool. 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 route trades sanctioned status for convenience.