Twitter Monitor Tool: Account Alerts by Webhook

// SETUP

How Twitter monitoring works

Three calls, all free. Register where events should go, tell a monitor which handle to watch, and send yourself a test delivery. From then on every post the account makes arrives as a tweet.created event. Deliveries to your own endpoint are signed with HMAC-SHA256 over the timestamp and the raw body, so your receiver can refuse anything that did not come from us.

# 1. Where events go. Save "secret" now, it is shown once.
curl -X POST "https://api.twitterapis.com/twitter/webhook" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com/hooks/x-posts"}'

# 2. Watch an account and point it at that webhook.
curl -X POST "https://api.twitterapis.com/twitter/monitor" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"handle": "nasa", "webhook_ids": ["wh_9f2a1c"]}'

# 3. Send a signed test delivery before you depend on it.
curl -X POST "https://api.twitterapis.com/twitter/webhook/wh_9f2a1c/test" \
  -H "Authorization: Bearer YOUR_API_KEY"

import time, requests

API = "https://api.twitterapis.com/twitter/tweet/advanced_search"
HEADERS = {"Authorization": "Bearer YOUR_API_KEY"}
QUERY = '"your brand" OR @yourhandle -filter:retweets'
seen = set()
MAX_PAGES = 3                          # a hard stop, so one loud term cannot run up the bill

def poll_once():
    params = {"query": QUERY, "product": "Latest"}
    for _ in range(MAX_PAGES):
        page = requests.get(API, headers=HEADERS, params=params, timeout=30).json()
        fresh = [t for t in page.get("tweets", []) if t["id"] not in seen]
        for tweet in fresh:
            seen.add(tweet["id"])
            handle(tweet)              # your alert, queue or database
        # stop when a page brings nothing new or there is no next page
        if not fresh or not page.get("has_more"):
            return
        params["cursor"] = page["next_cursor"]

while True:
    poll_once()
    time.sleep(15 * 60)                # 2,880 calls a month at one page per poll

// USE CASES

What teams monitor on Twitter

The jobs below all share one shape: a known list of sources, or a known set of words, and a system that has to act when either one produces something new. None of them needs a dashboard in the middle, which is where an API-first monitor is cheaper and faster to wire than a listening suite.

// LIMITS

Real-time Twitter alerts: latency and limits, stated plainly

Most monitoring pages say real-time and stop there. Here is what that means on this service, so you can decide whether it fits a trading bot or only a support queue.

• +Detection: monitors poll every watched account on a shared interval of about 60 seconds, the same on every plan. A new post is usually seen within a minute. It is a published design figure, not an SLA.
• +Delivery: after detection, the webhook is typically sent within about 2 seconds on Growth and above. On one measured production event detection took about 34 seconds and delivery about 3.6 seconds.
• +No backfill: a monitor delivers posts made after it was created. Read history once through the timeline or search endpoints.
• +Public accounts only: protected accounts and private messages of other people are out of scope.
• +No sentiment or dashboards: you get the post as data. Score it, chart it or summarise it in your own stack, or with an AI model through the MCP server.
• +No uptime figure: there is a live status page, and no published historical uptime number. We would rather say that than print one we cannot back.

Live service checks are on the status page. The Twitter webhook API page documents retries, signatures and the delivery log endpoint in full.

// ALERTS

Sending Twitter alerts to Slack, Discord, email or a queue

The shortest path is to register a Slack incoming webhook URL or a Discord webhook URL as the destination. Those URLs are recognised and each post arrives as a native message with the author, the text, a link and images, with no server of your own. Slack and Discord do not check signatures, so for anything that writes to a database or triggers an action, point the monitor at your own endpoint, verify the signature, then fan out.

import hmac, hashlib, time
from flask import Flask, request, abort

app = Flask(__name__)
SECRET = "whsec_..."  # from the create-webhook response

@app.post("/hooks/x-posts")
def receive():
    parts = dict(kv.split("=", 1) for kv in
                 request.headers.get("X-TwitterAPIs-Signature", "").split(",") if "=" in kv)
    t, sig = parts.get("t", ""), parts.get("v1", "")
    if not t.isdigit() or abs(time.time() - int(t)) > 300:
        abort(401)
    expected = hmac.new(SECRET.encode(), t.encode() + b"." + request.get_data(),
                        hashlib.sha256).hexdigest()
    if not hmac.compare_digest(expected, sig):
        abort(401)
    event = request.get_json()
    if event.get("event") == "tweet.created":
        enqueue(event["handle"], event["tweet"])   # Slack, email, a queue, a model
    return {"ok": True}

The same receiver can send email through your existing provider, write to a queue for a trading strategy, or hand the post to an agent. Agents can also manage monitors themselves through the MCP server, where every monitoring tool is free to call.

Twitter monitor FAQ