Twitter (X) Firehose API — A Developer's Guide
The word 'firehose' gets thrown around loosely in Twitter (X) API discussions. Sometimes it means the literal full unfiltered public tweet stream (X Enterprise, formerly PowerTrack v1.1). Sometimes it means 'a lot of tweets fast' (which any streaming endpoint delivers). The two matter differently for cost, compliance, and architecture.
This page draws the honest line: what the actual firehose is, what X Enterprise charges for it, and why the twitterapi.io filtered_stream + webhook combo covers the vast majority of dev workloads at a fraction of the price. Pricing references are URL-cited to the providers' own pages.
What 'firehose' actually means
Full firehose — every public tweet, in real time, delivered to your ingestion pipeline as it's posted. No sampling, no filtering, no delay. That's the technical definition and it's a specific product line: X Enterprise (formerly PowerTrack v1.1 + Decahose + Enterprise Search).
Filtered stream / near-firehose — you specify a rule set (keywords, accounts, geo, language) and receive every matching tweet in real time. Not the whole stream but the subset that matches. Sufficient for brand monitoring, trend detection, competitive intelligence, keyword-alert products.
Batch / polling — you query a search endpoint on a schedule. Not real time; useful for historical archival, backfill, offline analysis.
The confusion in dev-forums is real people using 'firehose' interchangeably for all three. This guide keeps the three distinct because the cost + architecture math is very different.
Path 1 — X Enterprise (the real firehose)
X's enterprise tier includes full-firehose access at documented pricing starting around $42,000/month for the smallest tier per docs.x.com/x-api/getting-started/pricing enterprise materials. Delivered via HTTP streaming with tap-and-hose semantics.
Who actually needs this: financial-grade signal aggregators (BloombergTerminal, quant funds), academic archival institutions (Library of Congress-style projects), enterprise crisis-monitoring platforms with SLA commitments. Multi-year contracts, dedicated support.
Who doesn't: 99% of dev projects. If you can define your interest as a rule set (keyword, account, geo, language filters), you don't need the whole hose.
Path 2 — twitterapi.io filtered_stream + webhook
Rule-based near-firehose without the enterprise contract. Register a rule via /oapi/tweet_filter/add_rule, provide a callback URL, receive matching tweets pushed to you as they're posted. No connection to keep alive on your side (the webhook pattern eliminates the streaming-connection maintenance).
Pricing per twitterapi.io/pricing: $0.00015 per returned tweet. For a rule matching ~10,000 tweets/day (a busy brand or keyword), monthly cost lands around $45. Same volume via X Enterprise = $42,000/month floor plus per-tweet cost — the ratio is roughly three orders of magnitude cheaper for the rule-based path.
# Register a rule (POST /oapi/tweet_filter/add_rule)
import os, requests
HEADERS = {"X-API-Key": os.environ["TWITTERAPI_IO_KEY"]}
BASE = "https://api.twitterapi.io"
r = requests.post(
f"{BASE}/oapi/tweet_filter/add_rule",
headers=HEADERS,
data={
"tag": "brand-monitor",
"value": '"YourBrand" -is:retweet lang:en',
"interval_seconds": 5,
},
timeout=15,
)
r.raise_for_status()
print(f"rule registered: {r.json()}")
# Set the callback URL for this rule in the twitterapi.io dashboard.
# Matching tweets get POSTed to your callback as they're posted.
# No streaming connection to maintain on your side.When path 2 stops being enough
Path 2 (rule-based filtered_stream) is not full firehose. Cases where it genuinely isn't enough and you need X Enterprise:
Undirected archival: you want every tweet regardless of content, for a research corpus or long-term analytical dataset. Filter rules can't capture 'everything'.
Statistical sampling for platform-level research: academic studies on the platform as a whole, requiring a representative unbiased sample. Filtered stream biases toward whatever your rules match.
Regulatory / compliance archival: financial or legal archival requirements that mandate 'all public posts within our jurisdiction'. Rule-based filtering doesn't satisfy an audit that demands totality.
Discovery use cases with unknown-unknown filters: you don't know yet what keywords or accounts will matter. Full firehose lets you archive first, filter later.
For every other case (brand monitoring, competitor tracking, trend detection, keyword-alert products, sentiment research, customer-support monitoring), path 2 covers it at ~1/1000 the price.
Side-by-side — 3 paths for streaming Twitter (X) data
Pricing per each provider's published documentation. Third column is polling batch pattern (not firehose but often confused with it).
Two practical observations: (a) the 33×+ cost ratio between twitterapi.io filtered_stream and X Enterprise per tweet compounds fast at any real volume; (b) the webhook pattern eliminates streaming-connection maintenance — a real ops advantage for teams without dedicated infrastructure.
Historical context — PowerTrack, Decahose, GNIP
The vocabulary shift matters when you're reading older documentation or blog posts. Before X's 2022-2023 API restructuring:
PowerTrack v1.1 — the rule-based firehose (predecessor of the current Enterprise filtered_stream). Shut down as a standalone product in 2023.
Decahose — 10% sample of the full stream. Sunset around the same time.
GNIP — Twitter's enterprise data resale arm, acquired 2014, wound down as X consolidated data licensing internally.
Modern equivalents live under docs.x.com/x-api/. Third-party providers like twitterapi.io fill the gap left by PowerTrack + Decahose retirement for developers who want rule-based near-firehose without enterprise contracts.
Picking the path
Product / dashboard / SaaS with rule-based monitoring → twitterapi.io filtered_stream + webhook. Cheapest per-tweet + no connection maintenance.
Batch analytics / historical research → twitterapi.io advanced_search polling. Same per-tweet cost + query patterns tuned to your analysis schedule.
Financial signal aggregator / academic full-archive / regulatory archive → X Enterprise. Multi-year contract, dedicated support, expensive but the only actual firehose product.
Most teams that arrive here searching 'twitter firehose api' don't need Enterprise — they need rule-based streaming and are budget-shopping. The honest answer is 'you probably want option 2 and it's ~1000× cheaper than option 1'.
# Practical example: brand-mention rule-based near-firehose with webhook fanout.
#
# 1. Register the rule (one-time setup)
# 2. Configure the callback URL in the twitterapi.io dashboard
# 3. Your webhook handler receives matching tweets in near-real-time
import os, requests
HEADERS = {"X-API-Key": os.environ["TWITTERAPI_IO_KEY"]}
BASE = "https://api.twitterapi.io"
def register_brand_rule(brand: str, tag: str = "brand-monitor"):
r = requests.post(
f"{BASE}/oapi/tweet_filter/add_rule",
headers=HEADERS,
data={
"tag": tag,
"value": f'"{brand}" -is:retweet lang:en',
"interval_seconds": 5,
},
timeout=15,
)
r.raise_for_status()
return r.json()
rule = register_brand_rule("twitterapi.io")
print(f"rule id: {rule.get('rule_id')}")
# Your webhook handler side (illustrative):
# POST /your/webhook/url
# Content-Type: application/json
# { "tag": "brand-monitor", "tweet": { ...full tweet object... } }
#
# Cost framing from twitterapi.io/pricing:
# 1,000 mentions/day × $0.00015 = $0.15/day = ~$4.50/month
# 10,000 mentions/day × $0.00015 = $1.50/day = ~$45/month
# Same volume via X Enterprise: $42,000/month floor + per-tweet fee. ~1000x delta.Questions readers ask
Is 'firehose' the same as the filtered_stream endpoint?
No. Full firehose = every public tweet, no filter, delivered in real time (X Enterprise). Filtered_stream = rule-matching subset in real time. Most developers who search for 'firehose' actually want filtered_stream because their use case defines an implicit rule (brand mentions, keyword monitoring, trend detection).
Can I get full firehose without an X Enterprise contract?
Not legitimately. X Enterprise is the only sanctioned full-firehose channel. Third-party providers like twitterapi.io offer rule-based near-firehose that satisfies most use cases at a fraction of the cost, but 'unfiltered every-public-tweet' streaming is enterprise-only in 2026.
What's the cost cutoff where X Enterprise becomes cheaper?
Roughly speaking, at ~250 million matched tweets per month (~8M/day) the twitterapi.io filtered_stream cost approaches X Enterprise entry-tier pricing per twitterapi.io/pricing math. Real workloads rarely reach that volume; brand monitoring at Fortune-500 scale usually lands at a few million matched tweets/month, well within the twitterapi.io economics.
How does the twitterapi.io webhook pattern compare to holding open an HTTP stream?
Webhook wins operationally: no connection to maintain, no reconnection logic, no back-pressure engineering. You expose an HTTPS endpoint; twitterapi.io POSTs matching tweets to it. For teams without dedicated streaming infrastructure, this is a real savings in engineering time on top of the per-tweet cost delta.
What replaced Twitter's PowerTrack v1.1 for developers?
For enterprise: X Enterprise's filtered_stream + full-archive search products (higher-priced descendants of PowerTrack). For everyone else: third-party APIs like twitterapi.io's filtered_stream + advanced_search endpoints, which cover the rule-based near-firehose gap left by PowerTrack retirement.
Is any of this scraping-adjacent from a ToS standpoint?
The paths above are officially-sanctioned API surfaces (X Enterprise) or provider-brokered API surfaces (twitterapi.io). Neither involves scraping the web frontend. ToS compliance depends on how you use the data downstream (commercial resale, model training, competitor targeting) — review the specific developer terms for your use case.
Continue
- Twitter (X) API — cluster hub
- Twitter (X) streaming API — 2026 status
- Rate limit exceeded on Twitter (X) — fixes
- Twitter (X) API in Python — complete guide
- 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