X API stream: what pay-per-use actually delivers

#Quick answer

The X API stream most people mean is Filtered Stream, GET /2/tweets/search/stream, and on pay-per-use it is the only streaming endpoint you can reach. You get 1,000 rules, one connection, roughly 4 to 5 seconds of latency, and a bill of $0.005 for every Post the stream hands you. Powerstream, the firehose, the 1% and 10% volume streams, the likes streams and webhook delivery are all behind Enterprise sales.

Last updated: October 2026

That is the part the rest of the internet gets right. What it leaves out is that a stream is the only endpoint on the X API where the invoice is written by other people's posting rate rather than by your code, and that every feature designed to make streaming survivable sits on the other side of a sales call.

#Five streaming surfaces, one of them yours

X ships more streaming endpoints than the docs index makes obvious, and they are not variants of each other. They differ in payload shape, in access, and in whether you can pay for them with a card.

Powerstream is the interesting one, because it is both the newest and the least documented elsewhere. It is X's answer to the old GNIP PowerTrack: 1,000 rules at 2,048 characters, rule management limited to 50 requests per 24 hours, and a localDcOnly=true parameter that pins you to a single datacenter so you skip replication lag. Connect with it and the response carries an x-powerstream-datacenter header plus a connection_metadata frame naming the datacenter.

The catch nobody mentions: Powerstream returns the legacy payload. Not data and includes, but text, truncated, favorite_count and a fully inlined user object. Any parser you wrote against v2 will need a second code path. X's own Powerstream page also contradicts itself in the space of two screens, stating a 1,000-rule limit in prose while the sample code comment says "up to 100".

#The cost model is not in the pricing page

Search docs.x.com/x-api/getting-started/pricing for the word "stream" and you get zero hits. The rate card lists Posts: Read, User: Read, Post: Create and twenty other rows, and never names a streaming endpoint.

Usage and Billing is where it actually lives, which lists Filtered Stream and Filtered Stream webhooks under "tracked endpoints" and then answers it directly in an FAQ accordion: each unique Post delivered through filtered stream counts toward usage, subject to daily deduplication. So a streamed Post is a Posts: Read at $0.005, and the same Post matched twice in one UTC day is charged once. The live rate card at console.x.com/api/credits/pricing, which is public and unauthenticated, confirms the event type: "Post": 0.005.

Now put that next to the delivery ceiling. X's rate-limit reference gives Filtered Stream 250 Posts per second.

• 250 Posts/second is $1.25 per second, or $75 a minute
• The pay-per-use cap is 3 million Post reads per billing cycle, which is $15,000
• At the full delivery rate, that cap is gone in 3 hours and 20 minutes

Nobody runs at the ceiling for three hours. The point is the shape of the risk. On X API search you set max_results and you know the worst case before you call. A stream has no page size. You write a rule, and the cost of that rule is decided by strangers. X's own high-volume guide warns that burst volumes "may reach 5-10x average daily consumption levels" during events, and a brand-name rule during a sponsorship moment is exactly that.

Three things actually help:

1. sample:, the operator almost nobody uses. #nowplaying @spotify sample:15 matches a random 15% of what the rule would otherwise deliver. It is a volume dial that works on the billable side.
2. Spending limits in the Developer Console, because there is no client-side way to stop delivery once the connection is open.
3. Narrower rules. Rule changes take effect in about 20 seconds without reconnecting, so tightening a rule mid-incident is cheap.

Our X API pricing breakdown has the rest of the rate card, including the $20 card-save credit X added in October 2026.

#Backfill, recovery and redundancy are all Enterprise

This is the gap that decides whether you can build a serious listener on pay-per-use.

X publishes a clean recovery decision tree. Disconnected for 5 minutes or less, reconnect with ?backfill_minutes=5. Disconnected for 5 minutes to 24 hours, use the Recovery feature with start_time and end_time. Longer than 24 hours, fall back to Search.

Read the fine print on the first two and they carry the same line: available for Enterprise access. Redundant connections, where two consumers receive the same data for hot failover, are Enterprise too, and capped at two for Filtered Stream. Pay-per-use gets one connection, no backfill, no replay.

So the real decision tree on a card-funded account has one branch: every disconnection goes straight to Search. And X flags, in its own warning box, that this is not equivalent. The Search endpoint does not support sample:, bio:, bio_name: or bio_location:, and it differs in how it handles accents and diacritics. A rule using any of those cannot be replayed at all. Since the May 2026 search index migration, keyword searches also stopped returning reposts while the stream kept delivering them, so even a replayable rule returns a different corpus.

Plan for gaps, log them, and be honest in your product about what "real-time monitoring" means when the pipe has no replay.

#The stream and Search speak different languages

People assume a rule and a query are the same string. They are close, and the differences are all in the places that matter.

Engagement-threshold operators being search-only makes sense once you say it out loud: a Post entering the stream is milliseconds old and has no likes yet. Filter on author attributes instead, which is why the stream gets the followers_count: family and Search does not.

embedding: is the one worth knowing about even if you cannot use it yet. It matches Posts by semantic similarity rather than keywords, with embedding_threshold: setting the minimum cosine similarity (default 0.3, X recommends 0.3 to 0.6). Matched Posts come back with embedding_similarity and embedding_threshold inside matching_rules, so you can tune on real scores. It cannot be negated, it cannot stand alone as a threshold, and rules take a few seconds to start matching because query processing is asynchronous. It is Enterprise with Embedding tier access; on anything else, rule creation is rejected with an "unavailable operator" error.

#The 429 that nothing clears, and the endpoint that clears it

Search the X developer forum for filtered stream problems and one error dominates across years:

{
  "title": "ConnectionException",
  "detail": "This stream is currently at the maximum allowed connection limit.",
  "connection_issue": "TooManyConnections"
}

A connection X still believes is open blocks the one you are trying to make, and you only get one. In a 2025 thread on this exact error, X staff advised the developer to "close all the connections properly and restart" - advice that does not help when the stale connection is on X's side. Another developer in the same thread reported killing their server, deleting every rule and waiting 24 hours with the 429 still live.

Reach for the Stream Connections endpoint group instead, which barely appears in third-party writeups: GET /2/connections returns active and historical connections, DELETE /2/connections/all terminates them, and there are variants that kill by endpoint or by UUID. The all-connections delete is rate limited at 25 requests per 15 minutes. Put it in a startup hook before you open a stream and that whole class of outage goes away.

While you are at it, note the other 429 source: connection attempts to /2/tweets/search/stream are capped at 50 per 15 minutes. A naive reconnect loop with no backoff spends that in under a minute and then locks itself out. Our X API rate limits guide covers how the per-app and per-user ceilings interact.

#Billing you cannot audit

On 8 October 2026 a developer posted that App 31315033, which runs nothing but Filtered Stream, was billed 14,204 Posts on 6 October. Their service logged 270 delivered. Every other day that month sat between 99 and 336. Rules unchanged since 21 September, no 429s, no second connection, no other API calls from that app.

X staff acknowledged the report the same day and opened a usage review. The developer followed up on 13 October. As of this writing the thread has no result.

Set aside whether it was a bug. The structural problem is that the reporter had to ask X for a per-endpoint breakdown, because the Usage API does not provide one. GET /2/usage/tweets returns daily_project_usage with a tweets_consumed integer per app per day, and that is the whole ledger. There is no split by endpoint, no count of Posts delivered per rule, no reconciliation against what arrived on your socket.

The practical answer is to build the ledger yourself. Count every Post your consumer receives, bucket it by UTC day and by matching_rules tag, and compare your number against /2/usage/tweets daily. Tag every rule, since matched Posts carry the tag back to you. If the two numbers diverge, you want to notice on day one, not at the end of the billing cycle.

#Three traps the docs set

The webhook card that is not for you. The Filtered Stream overview page advertises "Webhook delivery" as one of four headline features, with a link. The access-level table beside it says nothing about who can use it. Click through and the webhooks page states it is currently available to Enterprise developers. A developer on pay-per-use documented the sequence in February 2026: create the webhook (succeeds), validate CRC (succeeds), post the rules (succeeds), then link the stream to the webhook and get a 403 client-not-enrolled. Three green lights, then a wall.

Dead tier names in live docs. The high-volume capacity page still lists the delivery cap as "Academic | 250 Posts/second" and the volume streams page still says "With Essential access, you can have one connection at a time". Neither Academic Research nor Essential has existed since the pay-per-use migration. The numbers are probably right; the labels tell you how recently that page was reviewed.

Geo enrichment is degraded. A location-monitoring developer reported in June 2026 that point_radius, bounding_box and has:geo rules stopped matching, and that posts carrying a place_id returned "Could not find place with geo.place_id". By September the lookup errors had cleared, but includes.places[] was coming back with country, name and place_type and no geo object at all, with expansions=geo.place_id and place.fields=geo both set. X staff confirmed the shape on 8 September 2026 and said they were investigating. If your build depends on coordinates, verify before you commit to it.

#Do you need a stream at all

Three questions settle it.

Do you need seconds, or minutes? If minutes are fine, poll X API search on a schedule. You control page size, you control spend, and you can stop. If you need seconds for a firehose-shaped problem and you are not an Enterprise customer, the honest answer is that X does not currently sell you that. The July 2026 request to meter Powerstream per connection-hour on pay-per-use is still sitting there without a reply, and the same post notes pay-per-use streams can take 10 to 20 seconds just to start delivering after connecting.

Is it your own account's activity? Then you want the X Activity API and its webhooks, not a public stream. Account-level events push to you, there is no connection to babysit, and you are not paying to re-read the public timeline to find your own mentions.

Is this actually a growth problem? A lot of stream projects start as "I want to reply to the right conversations fast". That is a workflow, not an infrastructure problem, and the API route adds a second constraint on top of cost: since February 2026, self-serve tiers can only publish a reply when the original author mentioned or quoted you, which X API reply covers in full. If the goal is consistent posting and replying from your own account rather than a data pipeline, X-Autopilot runs that loop in your own browser on your own machine instead of through a metered endpoint. It is a different trade-off with its own risks, and we are explicit about those: browser automation is a gray area under X's automation rules, while the API route is the sanctioned one.

Pick the stream when the data volume is the product. Pick anything else when it is not.