X (Twitter) API Pricing in 2026: All Tiers

X API pricing has changed dramatically since 2022

Before 2023, X’s API was one of the most permissive major social APIs. Researchers, indie developers, and automation builders had broad free access to read timelines, search posts, and publish content. That era is over.

Following the 2022 acquisition, X rebuilt its pricing from scratch. The free tier was reduced to a write-only stub. The Basic tier was introduced, then repriced upward. And in February 2026, X replaced the entire model: pay-per-use is now the default pricing structure for the X API. The previous free tier is effectively discontinued, and the fixed monthly plans (Basic and Pro) are legacy options available only to existing subscribers.

This guide covers what each pricing option actually gets you, what the numbers mean for publishing-focused developers, and where the line falls between what you can do yourself and when using a publishing API makes more sense.

The pricing structure at a glance

As of April 2026, pay-per-use is the primary pricing model. Legacy fixed monthly plans remain available to existing subscribers but are no longer offered to new signups.

The free tier is no longer available to new developers. X restricts free access to “for-good public utility apps” on a case-by-case basis.

Pay-per-use: the new default (launched February 2026)

On February 6, 2026, X replaced its tiered pricing model with pay-per-use as the default. New developers are directed here by default — there is no free tier and no option to sign up for Basic or Pro as a new customer.

Developers purchase credits upfront in the Developer Console and are charged per API call:

Deduplication: Requesting the same post multiple times within a 24-hour UTC window counts as a single charge.

Cap: Pay-per-use is limited to 2 million post reads per month. Above that threshold, Enterprise is required.

What you get access to:

• Full read + write access to v2 endpoints
• Recent search (7-day window)
• User lookup, timelines, likes, follows, bookmarks
• DM read and write endpoints
• No streaming endpoints — those remain Pro/Enterprise only
• No full archive search — 7-day window only

Cost modeling for publishing use cases:

• 500 posts/month: $5.00 in post creation credits plus minimal reads. Far cheaper than the old $200/month Basic tier.
• 5,000 posts/month with 10,000 reads: $50 in writes + $50 in reads = $100/month.
• 50,000 posts/month with minimal reads: $500/month. Comparable to the old Basic tier but with more publishing headroom.
• At 100,000 reads/month: $500 in reads alone. Read-heavy workloads get expensive fast.
• At 2 million reads/month: $10,000. More expensive than the legacy Pro tier ($5,000).

Pay-per-use is most advantageous for publishing-heavy, read-light workloads. It is disadvantageous for read-heavy workloads.

xAI credit program: X offers credits back in xAI/Grok API credits based on cumulative API spend per billing cycle:

• Below $200 spend: no credits
• $200+ spend: 10% back
• $500+ spend: 15% back
• $1,000+ spend: 20% back

Free tier: effectively discontinued

The free tier is no longer available to new developers. Existing free-tier users were migrated to the pay-per-use model with a one-time $10 voucher. X now restricts free access to “for-good public utility apps” approved on a case-by-case basis.

Previously, the free tier allowed roughly 500 posts per month with no read access beyond GET /2/users/me. That access path no longer exists for new signups.

Basic tier: $200/month (legacy)

The Basic tier is no longer available to new signups. Existing subscribers can maintain their plans, but new developers are directed to pay-per-use instead.

For existing subscribers, Basic remains the minimum fixed-price option for any serious publishing or read-access use case.

What you get:

• Full read + write access to most v2 endpoints
• ~10,000–15,000 post reads per month (tracked at the project level, resets monthly)
• ~50,000 post writes per month
• Recent search (7-day window) — GET /2/tweets/search/recent
• User lookup, user timelines, likes, follows, bookmarks
• 2 app environments within the project
• 2 top-ups per month (additional quota in exchange for payment)

What Basic does not get you:

• Full archive search (historical beyond 7 days) — that requires Pro
• Streaming endpoints (filtered stream, sampled stream) — Pro only
• Academic or compliance data feeds — Enterprise only

Rate limits: 15-minute rolling windows apply to each endpoint independently, with separate per-app (Bearer Token) and per-user (OAuth context) limits:

Per-app limits and per-user limits are enforced independently. A single user hitting their 100 posts/15-minute per-user limit does not block other users of your app. HTTP 429 is returned on breach; the x-rate-limit-reset header gives the UTC epoch timestamp of when the window resets.

Annual pricing: $175/month billed annually ($2,100/year) saves ~12.5% over monthly billing.

Pro tier: $5,000/month (legacy)

Pro is no longer available to new signups. Existing subscribers retain access. Pro is designed for companies building products that genuinely depend on high-volume read access or streaming.

What you get:

• 1,000,000 post reads per month
• ~300,000 post writes per month
• Full archive search — historical data going back to the first tweet, not just 7 days
• Filtered stream (/2/tweets/search/stream) — real-time filtered stream of posts matching your rules
• Sampled stream (/2/tweets/sample/stream) — random 1% sample of all posts in real time
• Higher rate limits per endpoint
• 3 app environments

What Pro does not get you:

• Full firehose access — the complete real-time stream of all posts. That is Enterprise only.

Annual pricing: $4,500/month billed annually ($54,000/year).

Who actually needs Pro: Companies building social analytics platforms, news monitoring tools, or real-time event tracking products. If your use case is publishing content — posting on behalf of users or automating a brand’s social feed — Pro’s defining features (full archive search, streaming) are not what you need, and the $5,000/month price tag is not justified.

Enterprise: $42,000+/month

Enterprise is negotiated directly with X. Publicly cited entry-level pricing starts around $42,000–$50,000/month with fully custom terms. This tier includes:

• 50,000,000+ post reads per month
• Full firehose access — complete real-time stream of all posts on the platform
• Compliance data feeds — deletion, suspension, and edit event streams (required for applications with data retention obligations)
• Custom rate limits and a dedicated account manager

Enterprise applies to research institutions, large analytics platforms, and newsrooms with significant data contracts. It is not relevant to the vast majority of developers building social publishing tools.

Authentication: OAuth 1.0a vs. OAuth 2.0

Both authentication methods are supported on all tiers. There is no pricing tier restriction on which OAuth flow you use.

For publishing on behalf of users, both methods require user-level authentication — app-only Bearer Tokens cannot create posts. OAuth 2.0 with PKCE is the recommended path for new applications; some newer endpoints are OAuth 2.0 only. OAuth 1.0a still works and many existing integrations use it.

The compliance requirements developers miss

The pricing is only part of what determines whether you can actually use the X API for production. The compliance requirements add friction that is often underestimated:

Stated use case obligation: The use case description you submit during developer onboarding is contractually binding. Materially changing your use case requires notifying X and getting approval before the change. There is no casual “we pivoted” exemption.

Bot labeling: Automated accounts must clearly identify as bots in the profile bio. There is no grace period — this is a day-one requirement.

AI reply bots: Applications that use AI to generate and post replies require explicit prior written approval from X. This is not handled through the standard developer portal flow; it requires a separate sign-off.

Like and follow endpoint removal: As of August 2025, the free tier no longer has access to POST /2/users/:id/likes and POST /2/users/:id/follows. Applications that were using these endpoints on the free tier broke without warning.

Data deletion compliance: If a user deletes a post, applications with data storage obligations must honor that deletion. The compliance data feeds that provide deletion events are an Enterprise-only feature.

What this means for publishing-focused developers

If you are building a tool that posts to X on behalf of users — a scheduling tool, a cross-posting workflow, a content management product — here is what you are actually dealing with:

On Pay-Per-Use (the default for new developers): You pay $0.01 per post created and $0.005 per post read. For a publishing-focused product with minimal reads, this is straightforward and cheaper than the old Basic tier up to about 20,000 posts/month. The downside: no streaming, no full archive search, and costs scale linearly with no volume discount.

On Legacy Basic ($200/month): If you already have a Basic subscription, you can publish at volume with a fixed monthly cost and get 7-day search access. This remains the better deal for workloads above roughly 20,000 posts/month or with significant read volume. But new developers cannot sign up for this tier.

On Legacy Pro ($5,000/month): The additional capability beyond Basic is primarily full archive search and streaming. If your product does not need historical data or real-time event streams, the jump from $200 to $5,000 is hard to justify for a publishing-only use case.

The math for a multi-user publishing product — one managing dozens or hundreds of accounts — gets complicated on pay-per-use. If 50 users each post 10 times per day, that is 500 posts/day or 15,000 posts/month, costing $150/month in write credits alone. Add reads for confirmation and analytics, and costs climb further. On legacy Basic, the same volume is covered within the ~50,000 writes/month cap at a flat $200.

Publishing to X without managing per-call costs

The scenario Postproxy is built for: you want to publish to X as part of a multi-platform workflow without managing X API credit balances, tracking per-call costs, handling OAuth tokens per user, or worrying about the 2 million read cap.

curl -X POST "https://api.postproxy.dev/api/posts" \
     -H "Authorization: Bearer YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
       "post": {
         "body": "Your post content here"
       },
       "profiles": ["twitter"],
       "media": ["https://your-cdn.com/image.jpg"]
     }'

To post to X alongside other platforms in the same request:

curl -X POST "https://api.postproxy.dev/api/posts" \
     -H "Authorization: Bearer YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
       "post": {
         "body": "New post across all platforms"
       },
       "profiles": ["twitter", "instagram", "linkedin", "threads"]
     }'

Postproxy operates on Pro-tier X API access and handles the OAuth token lifecycle, rate limit tracking, and credit management internally. Your application does not need its own X developer account or pay-per-use balance.

This is the practical alternative when the X API’s per-call pricing model is more complex than the publishing problem actually warrants.

Timeline: how X API pricing changed

The direction has been consistent: pricing increases, access restrictions, and the removal of fixed-price tiers in favor of consumption-based billing.

Summary

For publishing-focused developers: pay-per-use is now the only option for new signups. It is cost-effective for write-heavy, read-light workloads — a developer posting 5,000 times per month with minimal reads pays roughly $50–100. Read-heavy workloads get expensive fast. If you already have a legacy Basic or Pro subscription, keep it if your usage pattern favors fixed-cost billing.

Connect your X account to Postproxy and start publishing through the Postproxy API — without managing X API credit balances, OAuth setup, or per-call cost tracking.