Twitter (X) Firehose Pricing — Enterprise vs API Comparison
The firehose price question comes up in two contexts: (1) enterprise dev-team asked to spec cost for a full unfiltered Twitter (X) data ingest, (2) product / SaaS dev-team wondering whether they need full firehose or if rule-based near-firehose is enough. The answer to the second decides the answer to the first — 99% of workloads don't need full firehose.
This guide walks the honest pricing per provider, the volume math where the delta compounds, and the specific workloads where full firehose actually pays off. Pricing references URL-cited to each provider.
The two price tiers — full firehose vs rule-based near-firehose
X Enterprise (full firehose): every public tweet, delivered in real-time, no filter. Enterprise pricing per docs.x.com/x-api/getting-started/pricing enterprise materials starts around $42,000/month for the smallest tier. Multi-year contracts, dedicated support, SLA commitments.
twitterapi.io filtered_stream + webhook (rule-based): register a rule, receive only tweets matching that rule. Priced at $0.00015 per matched tweet per twitterapi.io/pricing. No monthly minimum, no enterprise contract.
The delta between the two is not incremental — it's roughly three orders of magnitude at typical workloads. Understanding which pricing applies to which use case is 90% of the cost-decision.
Volume math — where the delta compounds
Small rule (brand mentions, ~500 tweets/day): rule-based $0.075/day = ~$2.25/month. Full firehose $42K+/month. Delta: 18,000×.
Medium rule (topic monitoring, ~10K tweets/day): rule-based $1.50/day = ~$45/month. Full firehose $42K+/month. Delta: 900×.
Large rule (broad keyword firehose, ~100K tweets/day): rule-based $15/day = ~$450/month. Full firehose $42K+/month. Delta: 90×.
Massive rule (multi-topic aggregation, ~1M tweets/day): rule-based $150/day = ~$4,500/month. Full firehose $42K+/month. Delta: ~10×.
Full unfiltered (everything, ~500M+ tweets/day): rule-based math doesn't apply. Full firehose is the only path.
When full firehose pays off
Full firehose is worth $42K+/month for these specific workloads:
Financial-grade signal aggregators: Bloomberg-tier products where seconds of latency + missing tweets is unacceptable + revenue justifies the spend.
Academic-archival institutions: LOC-style long-term preservation programs where 'archive every public tweet' is the mandate.
Regulatory compliance archival: legal-hold or jurisdiction-mandated archives that require totality, not filter-scoping.
Platform-level research: unbiased sampling for statistical study of the platform as a whole (filter rules bias the sample by matching only what you rule for).
Discovery use cases with unknown-unknown filters: you don't yet know what keywords or accounts will matter — full firehose lets you archive first + filter later.
Everyone else: rule-based near-firehose at $0.00015/tweet.
Side-by-side — full firehose vs rule-based
Two practical observations: (a) at Fortune-500 brand-monitoring scale, rule-based pricing lands somewhere between $50-500/month — a rounding error for the same team's other SaaS spend; (b) at TB/day archival scale, only full firehose covers the volume without engineering around per-tweet cost accumulation.
How to estimate your workload cost
Step 1: define your rule set. What tweets do you actually need? Brand mentions? Keyword firehose? Multi-account aggregation? Write out the query operators.
Step 2: sample-test the rule at low volume. Use twitterapi.io's advanced_search endpoint with the same query for a 24h window. Multiply the returned count by 30 for monthly volume estimate.
Step 3: apply the pricing. Matched tweets × $0.00015 = monthly cost via twitterapi.io. Compare against Enterprise $42K+/month floor. Unless you're in the specific full-firehose use cases above, path 1 wins by orders of magnitude.
Step 4: budget for growth. If your product succeeds, matched volume grows. Track $/tweet ratio; if you approach $42K/month in matched-tweet cost, revisit the full-firehose economics.
Common pricing pitfalls to avoid
Assuming 'firehose' means all of X's tweet volume: most 'give me the firehose' asks mean 'give me a lot of tweets fast'. Almost always a rule-based subset is what the requester actually needs. Clarify before repricing.
Undercounting matched tweets: rules that seem narrow ("YourBrand") can match more than expected once you include mentions, misspellings, and retweets. Sample-test before committing.
Ignoring downstream costs: streaming tweets is cheap; storing + processing them at scale isn't. Budget for warehouse ingest + query cost + retention policy in addition to per-tweet API cost.
Buying full firehose 'just in case': expensive insurance. Prefer starting rule-based + escalating if you demonstrably need full firehose. The $42K+/month is a real commitment.
# Practical example: rule-based volume estimation for firehose cost forecasting.
import os, requests
from datetime import date, timedelta
HEADERS = {"X-API-Key": os.environ["TWITTERAPI_IO_KEY"]}
BASE = "https://api.twitterapi.io"
def estimate_daily_volume(query: str) -> int:
"""Sample matched-tweet count over 24h for rule volume estimation."""
yesterday = (date.today() - timedelta(days=1)).isoformat()
today = date.today().isoformat()
full_query = f"{query} since:{yesterday} until:{today}"
tweets, cursor = 0, None
for _ in range(50):
params = {"query": full_query}
if cursor: params["cursor"] = cursor
r = requests.get(f"{BASE}/twitter/tweet/advanced_search", headers=HEADERS, params=params, timeout=15)
r.raise_for_status()
resp = r.json()
tweets += len(resp.get("tweets", []))
cursor = resp.get("next_cursor")
if not cursor: break
return tweets
def estimate_monthly_cost(query: str) -> dict:
daily = estimate_daily_volume(query)
monthly_tweets = daily * 30
twitterapi_monthly = monthly_tweets * 0.00015
x_enterprise_monthly_floor = 42000
return {
"rule": query,
"daily_volume": daily,
"monthly_volume": monthly_tweets,
"twitterapi_monthly_cost": round(twitterapi_monthly, 2),
"x_enterprise_monthly_floor": x_enterprise_monthly_floor,
"ratio": round(x_enterprise_monthly_floor / max(twitterapi_monthly, 0.01), 1),
}
# Estimate for a hypothetical rule
result = estimate_monthly_cost('"machine learning" min_faves:50 -is:retweet lang:en')
print(f"Rule: {result['rule']}")
print(f"Daily volume: {result['daily_volume']} tweets")
print(f"Monthly volume: {result['monthly_volume']:,} tweets")
print(f"twitterapi.io monthly cost: ${result['twitterapi_monthly_cost']}")
print(f"X Enterprise floor: ${result['x_enterprise_monthly_floor']:,}/mo")
print(f"Delta ratio: {result['ratio']}x cheaper via twitterapi.io")
# Costs from cited pricing pagesQuestions readers ask
Why is X Enterprise firehose priced so high?
It's an enterprise product bundled with dedicated support, SLA, multi-year contract, and unfiltered coverage of the entire public tweet volume. The absolute volume (500M+ tweets/day) is expensive to deliver at guaranteed real-time; the price reflects that infrastructure + the target customer (financial-grade + institutional).
Can I negotiate the X Enterprise price?
Enterprise contracts typically have negotiation levers (volume commitment, contract length, feature bundle). But the floor is real — sub-$40K/month tier isn't documented. If your budget is $10K/month you're in twitterapi.io rule-based territory, not enterprise.
What if I need real-time but only for one specific X account?
That's not firehose — it's Account Activity API territory. See /blog/twitter-webhooks-real-time-api-guide for the per-account webhook path. Cheaper than firehose + right-sized for the use case.
How does twitterapi.io keep the per-tweet price so low?
Volume + infrastructure amortization. Serving many customers off shared streaming infrastructure at sub-cent per tweet is workable; single-tenant unfiltered firehose isn't. Both models are legitimate; they serve different customer segments.
If my product succeeds, will I outgrow twitterapi.io?
Rarely. Even at 10× SaaS-brand-monitoring scale (multi-brand, multi-region) monthly matched-tweet volume typically stays in five-figure tweets/day, which is single-digit dollars per day at twitterapi.io rates. Full-firehose becomes the right call only when your workload requires the full unfiltered volume.
Is there a middle-tier between rule-based and full firehose?
X historically had Decahose (10% sample) and Sample-1% APIs for statistical work. Both sunset around 2023. Current landscape: full firehose OR rule-based. Multi-rule filtered_stream (register N rules matching your interests) covers most 'partial firehose' use cases at a fraction of full-firehose cost.
Continue
- Twitter (X) API — cluster hub
- Twitter (X) firehose API — developer guide
- Twitter (X) streaming API — real-time guide
- Twitter (X) API pricing
- twitterapi.io pricing
Stop reading. Start building.
Starter credits cover real testing on real data. Google sign-in, no card, no application queue.
Get an API key