Twitter Account Activity API: Polling Alternative

The Account Activity API is X's first-party webhook product. Rather than you asking for new data, X posts account events to an HTTPS endpoint you host, covering mentions, replies, follows, direct messages and similar activity for accounts that have authorised your app. It is enterprise-tier access, which means an application, an approved app, a subscription, and a public endpoint of your own that answers a CRC challenge and validates signatures on every delivery.

For one event type, yes. Register an HTTPS endpoint and we POST a tweet.created event to it whenever a handle you are monitoring publishes, so you do not poll for that. Each delivery is signed HMAC-SHA256 over the timestamp and the raw body in an X-TwitterAPIs-Signature header, and a failed delivery is retried on a schedule rather than dropped. Two bounds worth stating plainly. First, our side polls X on a 60-second interval, so an event typically reaches you within a minute of us seeing it, plus whatever lag X's own index adds. This is not sub-second push and we do not present it as streaming. Second, it covers new posts from a watched handle, not the rest of X's Account Activity set: mentions of you, replies, follows and DMs are still the polling loop described above.

Match the interval to how quickly a missed event actually hurts. Support triage and brand alerting are usually fine at 60 seconds, which is 43,200 calls a month per watch, roughly $34.56 at the standard rate for a single continuously polled account, or about $1.15 a month at a five-minute interval. Our own ceiling is 600 requests a minute per key, well above what any realistic polling schedule needs, so a tighter interval is a cost decision long before it is a rate one, and you can poll a high-value account fast while sweeping a long tail hourly.

Only for private surfaces. Mentions, replies, new posts, reposters and follower lists are public, so your Bearer token alone is enough. Direct messages are not public, so those read against a registered X session, which you set up once with a free call to POST /twitter/customer/session using auth_token and ct0 for the account you control. Everything else on this page needs no session at all.

Incremental polling covers most of the same ground at a fraction of the operational weight. Instead of hosting a webhook receiver, a scheduled job calls ordinary REST endpoints, stores the newest ID it has already seen, and treats anything above that watermark as a new event. TwitterAPIs bills those calls at $0.0008 each with no plan, so a mention watch polling once a minute costs roughly $1.15 a month. What you trade away is push latency: events surface within your interval rather than within seconds.

Store one value per watch: the highest post ID you have already processed. On each run, call GET /twitter/user/mentions for the account, walk the returned posts from newest down, stop as soon as you reach an ID at or below your stored watermark, and handle everything above it as new. Then save the new top ID. That loop is idempotent, so a duplicate run processes nothing twice, and it self-heals after downtime because the watermark has not moved while your job was off.

No, provided you page rather than only reading the first response. The watermark is what guarantees completeness: anything published between two runs still sits above your stored ID on the next call, so you catch it late rather than not at all. The one case that needs care is a burst larger than a single page. Keep following next_cursor until you reach an ID at or below your watermark, instead of assuming one page covers the gap.