Monitor Deliveries API

GET monitor/deliveries returns your most recent monitor delivery events across all monitors, newest first. Each event includes detected_lag_ms (time from tweet creation to detection) and delivery_lag_ms (time from queue to webhook POST), plus id, monitor_id, tweet_id, status, tweet_created_at, detected_at, delivered_at, and total_lag_ms. Results are capped by the limit parameter, default 50, max 200.

curl -X GET "https://example.com/monitor/deliveries?limit=50"

{  "deliveries": [    {      "id": "79a94efd-8b6c-46f7-afa5-1fecdf1250a1",      "monitor_id": "bd964ae0-7763-4dd6-9295-233d9badf6f9",      "tweet_id": "2087910515246784773",      "status": "delivered",      "tweet_created_at": "Thu Aug 13 14:33:52 +0000 2026",      "detected_at": "2026-08-13T14:34:25.984Z",      "delivered_at": "2026-08-13T14:34:29.580Z",      "detected_lag_ms": 33984,      "delivery_lag_ms": 3596,      "total_lag_ms": 37580    }  ],  "count": 1}

{  "error": "bad_request",  "message": "Missing or malformed parameter. Fix the request before retrying."}

{  "error": "unauthorized",  "message": "The API key is missing, malformed, or revoked. Check the Authorization header."}

{  "error": "insufficient_credits",  "message": "Your balance is exhausted. Top up your credits to continue."}

{  "error": "not_found",  "message": "The resource does not exist, for example a deleted tweet or a private account."}

{  "error": "rate_limited",  "message": "Too many requests. Back off and retry with exponential backoff."}

{  "error": "server_error",  "message": "Something failed on our side. Retry with backoff; if it persists, contact support."}

Pricing

When to use

Use this endpoint to audit what a monitor actually sent, including exact detection and delivery latency for each event, rather than to configure or list monitors themselves. Reach for it when a webhook consumer reports missing or delayed events and you need the per-event timing breakdown across all monitors, not just one.

Notes

• Scoped to your own key's deliveries only.
• detected_lag_ms measures the real gap from a post existing to us noticing it, the honest number for "how fast is monitoring" -- currently bound by the shared 60s poll interval, not a guaranteed SLA.
• A null lag field means tweet_created_at or delivered_at was unavailable for that specific event, not an error.

Related endpoints

• Create Monitor: Watch an X account for new posts and push them to your webhook(s).
• List Monitors: List every monitor on your account.

FAQ

How many delivery events can I fetch in one call, and what's the default?

Use the limit parameter, an integer from 1 to 200. If you omit it, the endpoint returns 50 events. Request 200 and paginate by timestamp on your side if you need a longer history than one call provides.

How do I tell whether a delay was in detection or in delivery?

Each event in the deliveries array carries detected_lag_ms (time from the tweet's actual creation to when the system detected it) and delivery_lag_ms (time from that detection queue to the webhook POST) separately, plus total_lag_ms as their sum. Compare the two fields to see whether a slow event was a detection problem or a delivery problem.