Pay-per-use X API accounts hit a hard 2 million post-read cap each month. Above that ceiling, X routes teams to Enterprise contracts quoted from roughly $42,000 per month. This page isolates only the Enterprise path: when it triggers, what procurement should budget, and what self-serve alternatives cover trend feeds without a sales cycle.
X's pay-per-use model works until it does not. A social listening product that pages through recent search results can burn through 2 million post reads in a single busy news cycle. At that point the Developer Console stops billing credits and the account needs an Enterprise contract. That transition is the subject here, not the per-endpoint rate card covered on the X API pricing comparison page.
Enterprise is also the path for teams that need filtered streams, compliance riders, or volume pricing before they hit the cap. The sales motion is slow, the commitment is annual, and the floor price dwarfs most trend-monitoring budgets.
X enforces a 2,000,000 post-read cap per calendar month on pay-per-use accounts. Post reads bill at $0.005 each under current rate cards, so the cap represents roughly $10,000 of metered consumption before the hard stop. User profile reads, trends reads, and owned-account reads at $0.001 may count on separate meters; verify current grouping in the Developer Console billing dashboard.
Common overflow paths:
| Pipeline pattern | Approximate monthly reads | Cap risk |
|---|---|---|
| 10 searches/day returning 100 posts each | ~30,000 | Low |
| Brand monitoring across 500 keywords, 200 posts each daily | ~3,000,000 | Exceeds cap |
| Filtered stream with broad rules | Variable, often millions | High |
| Daily trends endpoint only | Trends reads, not post reads | Low |
The surprise is multiplication. One search call that returns 100 posts is 100 billed resources, not one HTTP request. Teams sizing Enterprise should model expected result counts, not API call counts. The per-endpoint cost table maps each v2 family to its published credit rate.
X does not list Enterprise prices on the developer portal. Public estimates from procurement reviews and competitor comparisons cluster as follows:
| Cost element | Reported range | Notes |
|---|---|---|
| Monthly platform fee | $42,000 to $50,000+ | Entry quotes; volume discounts at scale |
| Contract term | 12 months typical | Multi-year for largest buyers |
| Per-resource rates | Negotiated | Often below $0.005/post at volume |
| Filtered stream | Bundled or add-on | Required for real-time firehose products |
| Onboarding | Weeks to months | Legal, security review, sandbox access |
Treat these as planning numbers, not quotes. Only X sales can bind a price. Vendr and G2 enterprise reviews occasionally surface actual contract values, but sample sizes are small and terms vary by use case.
Enterprise buyers typically negotiate:
Volume. Read limits above the 2 million pay-per-use ceiling, sometimes uncapped within contracted tiers.
Filtered streams. Real-time rule-based firehoses that would be impractical to emulate with polling search endpoints.
Rate cards. Discounted per-resource pricing when monthly volume is committed upfront.
Compliance. Data handling terms, deletion workflows, and audit support that regulated industries require.
Support. Named contacts, escalation paths, and sandbox environments for pre-production testing.
Team management. Multiple developer seats, role separation, and consolidated billing.
What Enterprise does not automatically solve: trend inference. Reading millions of posts still costs money even at a discount. Teams whose product only surfaces "what is trending on X right now" may be buying archive-scale infrastructure for a leaderboard-scale problem.
| Factor | Pay-per-use (under cap) | Enterprise |
|---|---|---|
| Signup | Self-serve in Developer Console | Sales-led |
| Monthly minimum | $0 platform fee; pay per resource | ~$42k+ platform fee |
| Post-read ceiling | 2,000,000/month hard stop | Negotiated, often higher |
| Rate visibility | Published per-resource table | Contract-specific |
| Commitment | None | Annual typical |
| Time to first API call | Hours | Weeks |
Legacy Basic ($200/month) and Pro ($5,000/month) subscriptions remain for accounts that enrolled before the 2026 pay-per-use switch. New projects cannot access those tiers. Some legacy Pro accounts delay Enterprise longer than pay-per-use accounts because their bundled allowances differ, but that path is closed to new signups.
Social listening platforms. Monitoring thousands of brand keywords with recent-search polling scales linearly with result page sizes. A mid-market listening product can exceed 2 million reads without an unusually large customer base.
Crisis monitoring. Breaking news spikes search result volume across every tracked term simultaneously. A single day can consume a month's cap.
Academic or research archives. Historical tweet collection for dataset construction is inherently read-heavy. Research teams often discover the cap during initial backfill, not steady-state polling.
Influencer analytics. Pulling recent posts for large influencer lists daily compounds quickly when each profile check adds user-read charges on top of post reads.
For each scenario, ask whether the product needs individual post text or only topic-level signals. The answer determines whether Enterprise is unavoidable or whether a trending feed plus cross-platform growth data covers the use case.
Teams that need ranked X trending topics, not tweet archives, can avoid both pay-per-use multiplication and Enterprise contracts.
Trends MCP exposes live X trending data through get_top_trends with type X (Twitter) Trending. One request returns ranked topic names as JSON. No X developer account, no per-post metering, no 2 million read cap.
Example request:
{
"mode": "get_top_trends",
"type": "X (Twitter) Trending",
"limit": 25
}
Pricing: 100 requests per month free on the Trends MCP pricing page. Paid plans start at $19/month for 1,000 requests.
Limitation: Live trending feed only. No historical X mention volume, no individual tweet text, no user timelines, no filtered streams. For those capabilities, the official X API (and eventually Enterprise) remains the path.
When it fits: Editorial dashboards, daily briefings, alert systems that fire when a new topic enters the top 25, and cross-platform checks that pair X spikes with Google Search growth on the same term.
Enterprise makes sense when the product is built on tweet-level data at scale. It is difficult to justify when the requirement is a daily snapshot of what X considers trending.
FAQ