X API Access: How to Get Keys and Tokens to Post

X API access starts in the X Developer Console at console.x.com: sign in with an X account, accept the Developer Agreement, create an app, and save the keys it generates. There's no free tier for new developers. X moved everyone new to pay-per-use on February 6, 2026, so you buy credits before your requests succeed. To post on someone's behalf you also need a user access token, from OAuth 2.0 with PKCE or OAuth 1.0a.

This guide covers the sign-up, the credentials, the access levels that still exist, and exactly which tokens let you post. Every X fact comes from X's developer docs, fetched 2026-10-12.

What do you need before you start?#

• An X account to sign in to the Developer Console. It becomes the owner of your developer app.
• A use case. X asks how you'll use the API when you complete your developer profile, and again for each app.
• A payment card for credits. Without credits, requests are blocked.
• A callback URL if other people will sign in to your app. OAuth 2.0 requires an exact match.

Step 1: Create a developer account#

Go to console.x.com and sign in with your X account. Then:

1. Accept the Developer Agreement and Policy. Read the part about end users before you build a product on self-serve access (more on that below).
2. Complete your profile. X asks for basic information about how you'll use the API.

Older guides send you to developer.twitter.com and describe Essential and Elevated access. X launched the Developer Console at console.x.com alongside pay-per-use, and its Getting Access guide now starts there.

Step 2: Create an app and save your credentials#

From the console dashboard, create a new app with a name, description, and use case. The console generates its credentials, and each one is shown only once, so store them in a vault right away. Losing one means regenerating it, which invalidates the old value.

Source: X Getting Access.

Turn on OAuth 2.0 in the app's authentication settings if you'll use it. The Client ID only appears in Keys and Tokens after you do. You also pick an app type there: Native App and Single page App are public clients with no secret, while Web App and Automated App or bot are confidential clients and get a Client Secret.

Step 3: Add credits#

Buy credits in the Developer Console before making paid requests. X deducts them per request for writes and per resource for reads. There are no subscriptions or minimums, and if your balance hits zero, X blocks requests until you top up.

What X charges per post and per read is in our X API pricing breakdown: $0.015 per post, $0.20 per post with a link, and $0.005 per post read. Set a spending limit in the console so a bug can't drain your balance.

What are the X API access levels now?#

For new developers there are two: pay-per-use (self-serve) and Enterprise (sales-led). The Free, Basic, and Pro tiers that most guides describe are closed or being folded into pay-per-use.

Sources: X changelog and X API pricing. The dates for the Basic and Pro migrations are in our pricing post.

Self-serve has two posting restrictions that Enterprise doesn't, per X's Manage Posts guide:

• Replies need a summons. A reply through the API only goes through if the original author @mentioned the replying account or quoted one of its posts.
• One cashtag per post. A post with more than one $TICKER is rejected.

Which tokens do you need to post on X?#

You need a user access token. The Bearer Token can't post. X's Create Post reference accepts two kinds of user context for POST /2/tweets:

OAuth 2.0 works with the X API v2 only. Sources: X OAuth 2.0 PKCE docs and the Manage Posts guide.

For your own account, the Access Token and Secret from Step 2 are enough. They represent the account that owns the app, which suits testing and personal bots.

For other people's accounts, run OAuth 2.0 with PKCE:

1. Send the user to the authorize URL. https://x.com/i/oauth2/authorize with response_type=code, your client_id, a registered redirect_uri, the scopes, a state, and a code_challenge.
2. Exchange the code fast. The authorization code expires 30 seconds after the user approves, so exchange it at https://api.x.com/2/oauth2/token right away.
3. Store both tokens. Request offline.access, or you get no refresh token and the user has to log in again every 2 hours.
4. Post with the user's token:

curl -X POST "https://api.x.com/2/tweets" \
  -H "Authorization: Bearer $USER_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"text": "Hello from the X API!"}'

Posts made this way show your app name as the source label, so keep the app's name and use case current.

How do AI agents get X API access?#

Through a developer app you own, like any other X API client. X hosts an MCP server at api.x.com/mcp, but X's MCP docs say its OAuth requires your own developer app and there's no dynamic client registration. You run X's xurl mcp bridge locally, which performs the OAuth 2.0 PKCE login and refreshes the token.

Two limits to know for agents:

• The MCP capability list doesn't include creating posts. X lists searching, reading posts and users, bookmarks, trends, news, and Articles. An agent that publishes posts still calls POST /2/tweets.
• Agent replies hit the summons rule. Since February 23, 2026, an agent on self-serve can't reply to posts unless the author @mentioned or quoted its account.

Is there a faster way to get X API access?#

Yes, if your users are the ones posting. With Adeli's X API, Adeli maintains the X developer app and has passed X's review, so your users connect their X accounts through Adeli's app and you never register one. X is live on Adeli, and one X account is one connected account on Adeli's pricing.

What Adeli handles, from the connect docs and X publish docs:

• The OAuth 2.0 flow. Adeli requests tweet.read, tweet.write, users.read, media.write, and offline.access. If a user withholds one, the connect fails with missing_scope and nothing is stored.
• Token refresh. Adeli refreshes every connected X account's tokens.
• Publishing. The same POST /api/v1/posts call as every other network, with platform: "x", up to 4 images or 1 video, and threads of up to 24 more posts.
• X's fees. X's API usage fees are passed through at X's published rates. X needs a card on file first, so until your workspace has one, connecting returns 402 x_billing_required. GET /api/v1/usage/x reports the month's running total (X API pricing docs).

Two things we saw building the X connection. X shows every user a warning that the app requests sensitive permissions and isn't affiliated with X, for any app that can post, and it can't be removed, so tell your users to expect it. And X can't publish a thread atomically: if a later post fails, the earlier ones stay live, and Adeli returns 207 with status: "partial" so you know where to resume.

If you only post from your own account, the console and an access token are all you need. If your customers connect theirs, or X is one of several networks, Adeli's posting API saves you the developer app, the OAuth flow, and the refresh job.