Twitter Webhook API
Stop polling for tweets. Register the X accounts you care about and every new post is pushed to your server as an HMAC-signed webhook within 2 to 15 seconds. No cron jobs, no firehose contract.
Last updated July 29, 2026. X API limits and pricing re-verified against X's own documentation on that date.
What is a Twitter webhook API?
A Twitter webhook API delivers new posts to your server by pushing them, rather than making you request them. You register the X accounts you want to watch and an HTTPS endpoint, and each new tweet arrives at that endpoint as an HMAC-signed POST within 2 to 15 seconds of publication. It replaces a polling loop, so there is no cron schedule, no last-seen-ID state and no wasted calls during the hours nobody posted.
Four Ways to Get New Tweets, and What Each Actually Costs You
The firehose was never available without an enterprise agreement. These are the options that remain.
| Approach | Latency | What you maintain | Availability |
|---|---|---|---|
| GetXAPI webhooks | 2s to 15s | One HTTPS endpoint | From $19/mo |
| Polling a read API | Your interval, plus drift | Cron, last-seen ID, backoff, dedupe | Billed per call |
| Official X filtered stream | Near real time | Held-open connection, reconnect, gap recovery | Enterprise tier |
| RSS bridges and trackers | Minutes | Scraping fragility, data locked in their dashboard | Varies |
Polling is the option most teams land on by default, and it is the one that scales worst. Watching 20 accounts on a 15-second interval is 4 calls per account per minute, which is 20 x 4 x 60 x 24 = 115,200 calls a day, whether or not anybody posted. The same 20 accounts on a $59 monthly plan cost nothing per delivery, arrive faster, and remove the cron, the state table and the dedupe logic from your codebase.
Three Calls to Stream Tweets in Real Time
- Create a webhook. A destination URL plus a signing secret, shown once and never returned again.
- Add a monitor. Which account to watch, which webhook to deliver to, standard or fast detection, replies on or off.
- Receive tweets. A signed POST within seconds of publication. Acknowledge fast, process asynchronously, dedupe on
delivery_id.
# 1. point a monitor at your endpoint (creates the webhook inline)
curl -X POST https://api.getxapi.com/twitter/monitor/add \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"userName": "elonmusk",
"webhook_url": "https://your-server.com/hooks/getxapi",
"tier": "fast"
}'Twitter Firehose Access, Pricing, and What Replaced It
The firehose is the full real-time stream of every public post. It was never sold openly: access came through enterprise agreements and a small set of resellers, priced in the tens of thousands of dollars a year, and it is still the case today that the closest official equivalent, the filtered stream, sits on the enterprise tier. There has never been a free firehose, and there is no self-serve firehose price list to compare against.
That matters less than it sounds, because almost nobody actually needs every public post. The real requirement is usually every post from a specific set of accounts, which is a much smaller problem. A webhook API solves that shape directly: you name the accounts, and delivery is pushed to you as they post.
Where you genuinely do need broad keyword coverage across all of X rather than a fixed account list, that is a search problem instead of a streaming one. The advanced search API sweeps the whole corpus on an interval you choose, and pairs well with webhooks for the accounts that matter most.
Sources: docs.x.com filtered stream for stream access and tier gating, developer.x.com/#pricing for pay-per-use read costs, and docs.x.com rate limits for per-endpoint windows. GetXAPI delivery, retry and signature behaviour is documented at docs.getxapi.com/docs/monitoring. X API figures last researched on July 29, 2026.
Twitter to Discord, Slack, and Telegram Bots
The most common thing built on this API is a bot that drops new tweets into a channel. Discord makes it short: create an incoming webhook under Channel Settings, Integrations, Webhooks, then point a monitor at a small endpoint of your own that verifies the signature and reshapes the tweet into an embed.
Send it straight to the Discord webhook URL and you are done in about twenty lines. The same shape works for Slack by swapping embeds for blocks, and for Telegram through the bot API. Three things people get wrong: verify against the raw bytes rather than re-serialized JSON, branch on the payload type because test deliveries carry no tweet, and dedupe on delivery_id because delivery is at-least-once.
The full walkthrough, with working verification code in four languages, is in the real-time monitoring guide.
Monitoring Plans
Flat monthly, separate from pay-per-call credits. Deliveries and retries are never billed per event.
| Plan | Price | Accounts | Per account | Fast 2s tier |
|---|---|---|---|---|
| Starter | $19/mo | 6 | $3.17 | Standard 15s |
| Growth | $59/mo | 20 | $2.95 | Yes |
| Professional | $119/mo | 50 | $2.38 | Yes |
| Enterprise | $249/mo | 150 | $1.66 | Yes |
Paying by card is an auto-renewing subscription you can cancel anytime. Paying by crypto buys a 30-day pass at the same price with bonus slots, and renewing early extends your end date rather than resetting it. If a subscription lapses your monitors are suspended rather than deleted, and everything revives on renewal.
Delivery Guarantees
- At-least-once. A tweet may arrive more than once. Dedupe on
delivery_id, which sits inside the signed body so it cannot be tampered with. - Signed. Every request carries an HMAC-SHA256 signature over
`${t}.${raw_body}`, timestamp-bound against replay. - Retried. Exponential backoff with jitter across 8 attempts, roughly 21 minutes, then dead-lettered.
- Ordered per account. Tweets from one account arrive in order. Different accounts may interleave.
- Forward-only. Monitoring starts from the moment you add it, so adding an account with 10,000 existing tweets will not flood you with 10,000 webhooks.
- Handle-change proof. Monitors follow the account's permanent numeric ID, so a rename never breaks tracking.
Start receiving tweets in real time
Register a webhook, add a monitor, and have your first delivery in minutes. From $19 a month for 6 accounts.
Frequently Asked Questions
Yes. GetXAPI real-time monitoring is a webhook API for X/Twitter: you register the accounts you want to watch and an HTTPS destination, and every new tweet is pushed to that endpoint as a signed POST within roughly 15 seconds on the standard tier or 2 seconds on the fast tier. X's own Account Activity API only covers webhooks for your own authenticated account's events, not arbitrary public accounts, which is why most teams end up polling or paying for enterprise streaming.
No. There has never been a free firehose, and the free X API tier carries no meaningful read allocation. Since X moved to pay-per-use in February 2026, reads are metered per resource, so even a modest streaming workload accrues cost quickly. Webhook monitoring is the practical alternative because it is billed as a flat monthly plan rather than per tweet delivered, and retries are never charged.
Create an incoming webhook in Discord under Channel Settings, Integrations, Webhooks. Then add a GetXAPI monitor pointing at a small endpoint of your own that verifies the signature, reshapes the tweet into a Discord embed, and forwards it to the Discord webhook URL. Verify against the raw request bytes rather than re-serialized JSON, and branch on the payload type because test deliveries contain no tweet field. The same shape works for Slack and Telegram.
No. Monitoring is a separate flat monthly subscription and deliveries and retries are never billed individually. Your pay-per-call credits are untouched, so a busy account that posts fifty times a day costs exactly the same as one that posts once.
The firehose is the historical name for the full real-time stream of every public post. Access has only ever been available through enterprise agreements and resellers, priced in the tens of thousands of dollars a year, and the modern equivalent on the official X API is the filtered stream on the enterprise tier. For the common case, which is watching a specific set of accounts rather than all of X, a webhook API covers the same job from $19 a month with no contract.
Invert the connection. Instead of holding a stream open and handling reconnects and gap recovery yourself, register a webhook and let each new post be pushed to you. Your server does nothing until a tweet exists, there is no connection to babysit across deploys, and delivery is retried automatically for about 21 minutes if your endpoint is down. Verify the HMAC signature on each delivery and dedupe on delivery_id, since delivery is at-least-once.
Detection is about 15 seconds on the standard tier and about 2 seconds on the fast tier, measured from publication to the outbound POST. Polling latency is your interval plus drift, so a 30-second poll averages 15 seconds of delay at best and costs a call every interval whether or not anything was posted. Watching 20 accounts on a 15-second poll is 115,200 calls a day (20 x 4 per minute x 60 x 24); the same 20 accounts on a $59 monthly plan cost nothing per delivery.
The delivery is retried with exponential backoff and jitter across 8 attempts, roughly 21 minutes in total. Retries fire on 408, 429, any 5xx, and network-level failures. Other 4xx responses are treated as permanent and dropped immediately, since a 404 or 410 means the endpoint is wrong. Anything still undelivered after the final attempt is dead-lettered and surfaced in the health endpoint's failed_24h counter.
Next read
Continue exploring related pages: