X API Pricing: Pay-Per-Use Credits + Legacy Tiers (Free, Basic, Pro, Enterprise) — What You Actually Get

You want the numbers, not the marketing. Here are the quotas, mechanics, and limits the X API actually enforces after the launch of Pay-Per-Use pricing, plus what still matters from the older Free/Basic/Pro world.

The punchline: pricing is no longer "pick a tier, live inside monthly caps." It's now credit-based pay-per-usage (pay only for what you consume), while rate limits still exist and still bite.

What changed: Pay-Per-Use pricing is now the default mental model

Old world (legacy tiers)

You bought a monthly plan (Free/Basic/Pro) and designed around:

monthly read caps
monthly posting caps
"post caps" (consumption caps)
top-ups (sometimes)

New world (pay-per-usage credits)

You design around:

what endpoints you call
how much data they return
deduplication rules
your credit balance and spending limits
rate limits per endpoint (still real)

The plan names are still noise. The billing and limits are the product.

Pay-Per-Use pricing: how it actually works

Mechanic	What it means in practice
Credit-based	You pre-purchase credits; requests deduct from that balance.
Per-endpoint pricing	Different endpoints cost different amounts (the current $ rates live in the Developer Console).
No monthly caps	There's no built-in "15k reads and you're done." You can keep going until your credits or spending limits stop you.
Real-time tracking	Usage and cost tracking is surfaced in the Developer Console while you build.
Usage is tracked at the app level	Your bill follows your developer app usage (not a vague "project total" mental model).
Enterprise still exists	High-volume customers can negotiate custom pricing/support/rate limits.

Important nuance: the docs are explicit that the current per-endpoint pricing numbers are in the Developer Console (not reliably mirrored on public pages). So if someone shows you a pricing screenshot, treat it as "may already be outdated."

Deduplication: the one rule that changes your caching strategy

Pay-per-usage billing comes with daily (UTC) deduplication:

Billable resources are deduplicated within a 24-hour UTC day window
Pull the same Post again in that window: it should not incur an additional charge
The window resets at midnight UTC
X describes this as a soft guarantee (rare edge cases like outages can break it)

Translated to engineering language:

You still cache (latency and rate-limits), but deduplication reduces the "double charge" penalty if you re-fetch the same IDs in the same day.
Design pipelines to avoid re-hydrating the same IDs across days unless you need updated fields.

What counts as billable usage

Posts retrieved from these categories count toward usage:

Category	Examples
Post lookup	`GET /2/tweets`
Search	recent search, full-archive search
Streaming	filtered stream (and webhooks)
Timelines	user posts, user mentions
Engagement	liked posts, bookmarks
Lists	list posts
Spaces	spaces lookup

Two more billing rules that matter:

Only successful responses that return data are billed (failed requests do not count).
Streaming billing is based on unique posts delivered, subject to daily deduplication.

Controlling spend: how to avoid "surprise invoice" stories

Pay-per-use has fewer cliffs, but more ways to accidentally set money on fire.

1) Spending limits (hard stop)

You can set a max spend per billing cycle; once hit, requests are blocked until the next cycle.

2) Auto-recharge (keep services running)

You can auto-top-up your balance based on a threshold:

"Trigger when balance < $X"
"Recharge amount = $Y"

3) Credit balance behavior (including going negative)

X notes that your balance can go slightly negative, and your API requests will be blocked until you add credits to cover it.

4) Cache + dedup-aware design

Deduplication helps, but it is not magic. You still win by:

caching hydrated Posts
storing IDs from search/stream results and avoiding re-hydration
keeping queries tight (especially for search)

Monitoring usage programmatically

You can pull usage data via the Usage endpoint (daily Post consumption counts). This is the simplest building block for alerts and budget enforcement.

Example call:

curl "https://api.x.com/2/usage/tweets" \
  -H "Authorization: Bearer $BEARER_TOKEN"

If you are doing anything serious, wire this into:

budget alerts
anomaly detection (spikes in search usage are common)
cost attribution per feature or customer

Rate limits still exist (and are separate from billing)

Pay-per-use did not remove rate limits. It just decoupled pricing from monthly caps.

X documents rate limits per endpoint, generally shown as:

Per App
Per User
mostly per 15-minute windows (unless otherwise noted)

You can also read rate-limit headers in responses:

x-rate-limit-limit
x-rate-limit-remaining
x-rate-limit-reset

A few concrete examples

Endpoint	Per App	Per User	Notes
`GET /2/tweets`	3,500 / 15 min	5,000 / 15 min	Lookup (batch)
`GET /2/tweets/:id`	450 / 15 min	900 / 15 min	Single lookup
`GET /2/tweets/search/recent`	450 / 15 min	300 / 15 min	10 default, 100 max results
`GET /2/tweets/search/all`	300 / 15 min + 1/sec	1/sec	Full archive; larger query lengths for Enterprise
`POST /2/tweets`	10,000 / 24 hrs	100 / 15 min	Create posts

Engineering takeaway: rate limits are your throughput ceiling; credits/spending limits are your budget ceiling. Design for both.

Search access: what's available to whom (and why it matters)

Search has become cleaner to reason about:

Recent search: last 7 days, available to all developers
Full-archive search: complete archive, available to Pay-per-use and Enterprise

That makes "search/backfill" workloads much more about cost and rate limiting, and less about "which tier do I have?"

Enterprise: still the "talk to sales" layer

For high-volume and custom needs, X positions Enterprise as:

dedicated support
custom rate limits
volume discounts or custom pricing
"complete data access" style options

If you are at the point where you are negotiating, the public docs stop being your limiting factor anyway.

Legacy subscription tiers (Free / Basic / Pro): where they still show up

X calls out that legacy Basic/Pro subscription packages may still exist for some accounts, and you can:

opt in to pay-per-use from the Developer Console
switch back to the legacy plan from settings

If you are starting fresh today, assume:

Pay-per-use is the default pricing path
legacy tiers are "legacy" for a reason (availability may vary)

Practical advice: treat legacy tier quotas (reads/posts/top-ups) as historical context unless the Developer Console shows you those plans as purchasable for your account.

FAQ

Does X API still have monthly caps?

Pay-per-usage pricing is described as having no monthly caps; you pay based on usage and can keep going until you hit spending limits or run out of credits.

What happens if I run out of credits?

Requests fail until you buy more credits. Auto-recharge and alerts are how you avoid downtime.

Do failed requests get billed?

No. Only successful responses that return data are billed.

Is deduplication guaranteed?

X describes deduplication as a soft guarantee: it applies in most cases, but rare edge cases (like outages) can break it.

Where do I find the actual $ pricing per endpoint?

In the Developer Console. Public docs explain the model and what is billable, but current per-endpoint rates are shown in-console.

Bottom line

In 2026, the X API product is not "Free vs Basic vs Pro."

It's:

pay-per-usage credits
billable endpoints and what they return
daily deduplication
endpoint rate limits
spending controls and monitoring

Build around those. Everything else is branding.

Endpoint	Pro	Basic	Free
`GET /2/compliance/jobs`	150/15m A	5/15m A	1/15m A
`GET /2/compliance/jobs/:job_id`	150/15m A	5/15m A	1/15m A
`POST /2/compliance/jobs`	150/15m A	15/15m A	1/15m A
`GET /2/usage/tweets`	50/15m A	50/15m A	1/15m A
`GET /2/trends/by/woeid/:id`	75/15m A	15/15m A	-
`GET /2/users/personalized_trends`	10/15m U; 200/15m A	1/15m U; 20/15m A	1/15m U; 1/24h A
`GET /2/communities/:id`	300/15m U; 300/15m A	1/15m U; 25/15m A	1/15m U; 1/15m A
`GET /2/communities/search`	18/15m U; 300/15m A	1/15m U; 25/15m A	1/15m U; 1/15m A

Sources: Rate limits table (Compliance/Usage/Trends/Communities). (X Developer Platform)

Effective cost at the cap (simple math, nothing magical)

If you actually hit caps, this is what you are paying per allowed unit. This is not what X bills you per request. It is just price divided by maximum included quota.

Plan	$/1k reads at cap	$/1k app-level posts at cap
Basic ($200/mo)	$200 / 15k = $13.33 per 1k reads	$200 / 50k = $4.00 per 1k posts
Pro ($5,000/mo)	$5,000 / 1,000k = $5.00 per 1k reads	$5,000 / 300k = $16.67 per 1k posts

Caps and pricing used here come from the official plan page. (X Developer)

What's not publicly quantified (so you will not find it in the reference)

Top-up pricing/size: the plans say "2 top ups" for Basic/Pro, but public docs do not spell out price per top-up or how many reads/writes you buy per top-up on the public pages we can access. (X Developer)
Enterprise exact quotas: public pages give "starts at $50k/month" and "50+ million Posts/month" post cap, but the actual SKUs, add-ons, and contract terms are sales-driven. (X Developer)

Bottom line

The plan names are noise. The caps and rate limits are the product. If you are building on the X API, design around the Post cap and per-endpoint limits, not the marketing tier.

If you are comparing API costs across platforms, see my breakdown of direct provider image and video generation pricing here: /blog/direct-provider-pricing-image-video-generation-apis.