Why WALLAWHATS Can Deliver X Alerts at $5/mo: Under the Hood

If you’ve ever tried to build your own X (Twitter) monitoring tool, you’ve hit the same wall we did: the API is not free, and the pricing is not simple. A lot of side projects and internal tools quietly die at this stage — the founder does the math, sees a bill that scales linearly with every account they want to watch, and shelves the idea.

WALLAWHATS ships a Pro plan at $5/month that covers 50 monthly alerts across 3 monitored X accounts, delivered to WhatsApp within seconds of the original post going live. This article is the honest version of “how” — the actual unit economics of the filtered-stream API, where the real costs sit, and where the savings come from. No hand-waving, no invented numbers we can’t stand behind.

The pay-per-use reality of the X API

X’s developer platform moved away from flat, cheap access a while back. Today, serious programmatic access to the public post stream is billed on a pay-per-use basis, with a per-post cost that adds up fast once you’re watching more than a handful of accounts. Roughly speaking, every post that matches a tracked rule and gets delivered to your stream carries a cost in the neighborhood of half a cent — call it $0.005 per matched post, as an illustrative unit cost. That number moves with X’s pricing changes over time, but the shape of the problem doesn’t: cost scales with volume of matched posts, not with the number of end users who want to see them.

That distinction is the whole story. If ten people each build their own bot to watch the same public account, ten separate systems pay the per-post cost for the exact same tweet. That’s the naive approach, and it’s why most hobbyist “tweet-to-notification” scripts either rack up surprising bills or get throttled into uselessness the moment more than one or two accounts are involved.

The filtered-stream model, not polling

The first efficiency gain has nothing to do with sharing across users — it’s about how you watch an account in the first place.

A polling approach — repeatedly asking “has this account posted anything new?” — wastes API calls on empty checks. Most public accounts don’t post every few seconds; they post a handful of times a day, with occasional bursts. Polling every account every few seconds to catch that burst means paying for thousands of empty responses to catch a handful of real ones.

WALLAWHATS instead subscribes to the filtered-stream endpoint: a persistent connection where X pushes matching posts to us the moment they’re publicly visible, instead of us asking over and over. We only pay for posts that actually match a tracked rule — not for the silence in between. This is the single biggest reason WALLAWHATS can promise near real-time delivery (“within seconds, when available” — X never guarantees sub-second delivery, and neither do we) without burning budget on idle polling.

Sharing rules across subscribers

The second — and bigger — efficiency gain is what actually makes a $5/month plan with real margin possible: rule sharing.

Here’s the mechanic. When you add @handle as a subscription in the WALLAWHATS dashboard, we don’t spin up a dedicated, private filtered-stream rule just for your account. We check whether @handle is already being tracked by another subscriber. If it is, your subscription rides on the existing rule — the underlying API cost for matching that account’s posts is already being paid once, and it’s shared across every subscriber watching that handle.

This matters enormously in practice, because X monitoring interest is not evenly distributed. A small number of accounts — major news outlets, large crypto exchanges, popular framework maintainers, well-known executives — attract a disproportionate share of subscriber interest. A handle like a major news account might be tracked by hundreds of WALLAWHATS users simultaneously, but the filtered-stream cost for matching that account’s posts is paid once, not hundreds of times. The savings compound: the more overlap there is between what our subscriber base wants to watch, the lower the effective per-user cost gets.

This is also why WALLAWHATS’ plan tiers cap the number of accounts you can monitor, not some artificial “API calls” metric you’d have to reason about yourself. Free gives you 2 X accounts, Pro gives you 3, Pro+ gives you 10, Business gives you 20, and Enterprise gives you 50 — a limit expressed in the terms that actually matter to you, while the API cost-sharing happens invisibly underneath.

Where the velocity cap fits into the cost picture

There’s a second lever that keeps costs predictable, and it’s not really about the X API bill at all — it’s about WhatsApp delivery and infrastructure load. Each plan has a velocity cap (alerts per hour, on a rolling 60-minute window, per user). When a monitored account goes into a rapid-fire posting streak — breaking news, a product launch thread, a volatile market day — additional posts past your plan’s cap don’t get dropped. They’re buffered into a digest table and flushed every 15 minutes by an EventBridge-scheduled job, arriving as one digest message per (user, handle) pair instead of a dozen separate pings.

This isn’t primarily a cost-cutting trick on the X side — the filtered-stream rule already matched those posts once, shared across subscribers, regardless of how many of them get bundled into a digest. The velocity cap exists mostly to protect you from notification floods. But it also keeps our downstream WhatsApp and email sending volume proportional and predictable, which is a real, if smaller, part of keeping per-user costs sane at scale. We’ve written a full breakdown of how velocity caps and digest batching work if you want the mechanics.

What this doesn’t cover — the honest gaps

A few things worth being upfront about, because “under the hood” articles are only useful if they’re honest about the edges:

• We don’t promise “every” tweet. The filtered-stream and recent-search APIs have edge cases — protected accounts, posts deleted mid-flight, brief outages, geo-restricted content. WALLAWHATS refuses subscriptions to protected or follower-only accounts by design, and frames delivery as “near real-time,” not “guaranteed complete.”
• We don’t re-broadcast private content. Everything WALLAWHATS delivers comes from the public filtered stream — an opt-in subscriber choosing to follow a public account’s public posts, verified to their own WhatsApp number or email.
• X’s pricing can change. The per-post cost figure above is illustrative of the current shape of the market, not a locked-in contract. If X’s pricing model shifts meaningfully, plan pricing and limits are the lever that moves, not silent quality degradation of the alerts you already have.
• Snapshots aren’t a permanent archive. Tweet snapshots (the rendered PNG that ships with every email alert, plus the 30-day searchable gallery) are retained for 30 days, matching our S3 lifecycle policy — not an “immutable record of every post.”

A worked example: one popular account, many subscribers

Numbers make this concrete. Say a well-known crypto exchange’s account posts 20 times in a day, and 300 different WALLAWHATS subscribers are all monitoring that same handle (a realistic scenario — see our guide on tracking crypto accounts on X for why that audience overlaps so heavily on a small set of exchange and analyst handles).

Under a naive, one-rule-per-user architecture, that’s 20 matched posts × 300 independent rules = 6,000 billed matches for a single day of one account’s activity. Under a shared-rule architecture, it’s 20 matched posts, once, distributed to the 300 subscribers who asked for them. The API cost didn’t change with the size of the audience — only the value delivered did.

That’s the inversion that makes a $5/month, 3-account Pro plan sustainable: cost is driven by how many distinct accounts the whole subscriber base wants to watch, not by how many people want to watch each one. A handful of very popular accounts (major news outlets, top exchanges, well-known maintainers) get watched by huge overlapping subscriber pools, and the marginal cost of the 301st subscriber to a popular handle is close to zero. A subscriber who only follows obscure, rarely-checked accounts costs more per-alert to serve — which is also, honestly, part of why plans cap the number of accounts rather than charging a flat per-account fee regardless of popularity.

Why not a free scraper or an RSS bridge?

A fair question, since free or near-free alternatives to the official API exist — third-party scraping tools, unofficial mirrors, RSS-to-notification bridges built on scraped pages. We don’t use those, for a few practical reasons worth being upfront about:

• Reliability. Scraping-based tools break every time the underlying page markup changes, and there’s no SLA or notice period — your alerts just silently stop one day.
• Compliance. WALLAWHATS operates through the official filtered-stream API under the X Developer Agreement. That’s the same access path that lets us honestly promise things like “we don’t re-broadcast protected content” and “we link back to the source post” — guarantees that are much harder to stand behind on top of an unofficial scraper.
• Latency and completeness. The official push-based stream tends to be faster and more consistent than polling a scraped page, especially for accounts posting multiple times in quick succession.

The tradeoff is that official access costs money per matched post — which is exactly the cost this article has been explaining how we absorb through shared rules and push-based delivery, instead of passing it straight through to you as a per-account surcharge.

Why this matters if you’re evaluating alternatives

If you’ve looked at building this yourself — a small script polling the X API, or a Zapier/IFTTT chain watching an RSS bridge — the economics above are exactly why those approaches tend to break down at any real scale. A single-user script pays full price for every post it matches, with no one to share the rule cost with. It works fine for one account, one user. It stops being cheap the moment you want to watch ten accounts, or the moment a friend asks you to add theirs too.

WALLAWHATS’ shared-rule architecture is the reason the math works the other direction: more subscribers watching overlapping accounts makes the whole system more efficient, not less. That’s also part of why the API is available on every plan, including Free — if you want to pull your own notification history or manage subscriptions programmatically, that access isn’t gated behind an enterprise tier.

The bottom line

WALLAWHATS keeps a $5/month plan viable through three concrete mechanisms, not marketing math:

1. Push, not poll. The filtered-stream connection means we only pay for posts that match, not for the silence between them.
2. Shared rules across subscribers. Popular accounts get tracked once and the cost is split across everyone watching them, not multiplied by subscriber count.
3. Velocity caps and digest batching. Notification volume stays predictable and proportional, protecting both your attention and our delivery infrastructure during bursty periods.

None of this requires you to understand any of it to get value from it — you add an @handle, verify a WhatsApp number, and alerts start arriving. But if you were wondering how a real-time X-to-WhatsApp service stays affordable instead of quietly capping out or degrading service, that’s the honest answer: better infrastructure decisions, not corners cut on what you actually experience. If you want to see what the alert itself looks like once it lands, our overview of X-to-WhatsApp alerts walks through the full flow.

Never miss an important post again. Create a free account — 1 WhatsApp number, real-time alerts, no credit card required.