Skip to main content
GET
Twitter Account Activity Tracker & Monitor Status

Check One Twitter Account Activity Tracker

Use this route for one Twitter account activity tracker status check. It returns the tracked X profile, selected event types, active state, and billing timing. Use update to change event filters or pause the monitor. Use list for the complete monitor inventory.
Free - does not consume credits
The Node.js, Python, and Go examples produce one normalized monitor snapshot. Store monitor_id, event_types, is_active, next_billing_at, update_endpoint, events_endpoint, event_detail_endpoint_pattern, webhooks_endpoint, and deliveries_endpoint_pattern before changing filters, pausing alerts, or reconciling webhooks.

State Handoff

Use GET /monitors/{id} before changing routing, billing checks, or alert state for one account monitor. The endpoint returns the current stored monitor for your account only; deleted or cross-account IDs return 404.

Tracked Account

Treat username and xUserId as the resolved X account identity. Store both with downstream CRM, warehouse, or queue records.

Current Filter

Treat eventTypes as the active matching contract. Mirror those event types into webhook subscriptions before relying on signed alerts.

Active State

Use isActive to decide whether the monitor should poll and bill. Use Update Monitor to pause or resume it.

Event Join

Use id as monitorId with List Events to reconcile stored events and webhook deliveries for this account.

Event Detail

Use event IDs returned by List Events with Get Event when a support, audit, or agent workflow needs the full tweet payload.

Webhook Alignment

Use List Webhooks to compare webhook eventTypes with this monitor before relying on signed alerts.

Delivery Audit

Use List Deliveries for each webhook and join delivery streamEventId to event IDs. Do not use x_event_id as the delivery join key.

What Does Twitter Account Activity Tracker Status Prove?

The response proves which X profile one monitor targets. Confirm both username and xUserId. Keep the stable X user ID when a username changes. A stable X user ID preserves identity after username changes. Read eventTypes as the monitor’s current matching contract. Tweet filters include new posts, replies, quotes, reposts, media, links, and polls. Additional filters detect mentions, hashtags, and long-form posts. Profile filters cover avatar, banner, name, username, biography, location, and URL. They also cover verification, protection, pinned tweets, and account availability. The response returns only the selected filters. Followers and following are not monitor event types. Account relationship changes are not monitor events either. For follower growth, compare complete follower snapshots at approved intervals. Use the follower export guide to create controlled follower CSV snapshots. Read isActive as the polling state. Active monitors capture selected future account changes. Pausing retains the profile and filters while disabling future monitoring. Read nextBillingAt as the next scheduled charge. It does not prove that an event or webhook delivery succeeded.

How Do I Check Whether Twitter Account Activity Alerts Are Active?

Check the monitor before diagnosing a missing alert. A healthy account alert requires four aligned layers. First, confirm the tracked profile. Next, find the expected type in eventTypes. Then verify isActive. Query List Events with this monitor ID. Finally, join the stored event to webhook deliveries through streamEventId. Do not treat one active flag as complete health evidence. The monitor may poll correctly while a webhook fails. A webhook may also work while the monitor omits the expected event type. Keep configuration, event, and delivery checks independent during diagnosis.

How Do I Track Mentions and Replies for One Account?

Confirm that eventTypes contains tweet.mention for mentions. For reply alerts, require the tweet.reply event type. Configure either event type independently or enable both together. The status route shows the stored selection. It does not return the matching tweets. Use List Events with monitorId after confirming the filters. Filter stored events by the required type and time window. Open the complete record through Get Event. The response contains the matched tweet payload. Add any missing filter before monitoring future alerts. Resume a paused monitor when the filter already exists. If both checks pass, trace the stored event and its webhook delivery. Never infer missing tweet activity from one failed receiver attempt.

Does This Endpoint Return Account Analytics or Historical Reports?

No. This endpoint returns one monitor configuration. It does not calculate engagement rate, follower growth, posting frequency, reach, impressions, or sentiment. It also does not backfill a native X analytics report. Monitor event history begins after monitor creation. List Events returns cursor-based pages of stored event records. Call X user tweets when an audit requires recent profile posts. Use an extraction job for follower CSV exports. Keep these outputs distinct. A monitor status snapshot explains configuration. An event record proves one matched change. A delivery record proves one webhook delivery attempt. A follower export records a dated follower list. None of those outputs is an engagement analytics dashboard.

How Do Twitter Analytics Tools Differ From Monitor Status?

Twitter analytics tools usually calculate performance from posts and account metrics. They may summarize likes, replies, reposts, views, or follower changes. Those values are engagement metrics. This endpoint reports the saved profile, filters, and polling status. The response describes one saved monitor. It identifies the tracked account and selected event filters. It also reports whether monitoring continues. The response never calculates reach, impressions, engagement rates, or audience growth. Check monitor status before investigating account activity. First, confirm the stable xUserId. Then inspect eventTypes and isActive. These fields prove whether Xquik could capture the expected change. They do not prove that the change occurred. Use List Events to find changes captured by the monitor. Open each event before making an activity claim. Use webhook deliveries to verify receiver attempts. This workflow separates monitor configuration from analytics reporting. Do not compare an empty event list with a complete analytics report. Event history begins when the monitor captures a selected change. Paused monitors do not capture additional account events. Omitted filters cannot produce corresponding event records. Record both conditions before drawing activity conclusions.

What Should a Twitter Account Activity Audit Store?

Start an audit with the monitor response. Store id, username, and xUserId. Add eventTypes, isActive, createdAt, and nextBillingAt. Together, these fields form one reproducible monitor snapshot. Record the request timestamp beside the response. The endpoint returns monitor creation time, not the audit observation time. Keep the HTTP status and monitor ID with that entry. Record the intended event beside the stored filters. For a reply alert, record the tweet.reply type. For a profile-name change, record profile.name. This comparison shows whether the required filter existed during the review. When an event exists, store its event ID and monitorId. Open the event and confirm its type. Then connect delivery streamEventId values to that event ID. Store each deliveryId and delivery status. This chain distinguishes a missing event from a failed receiver. Repeat the status request after each approved update. Compare the account, filters, polling status, and next scheduled charge. Preserve both snapshots with the approved change ticket. Reject the update when xUserId unexpectedly changes. Treat 404 as an ownership or existence failure. Never infer previous monitor states from that response. Before continuing, confirm the authenticated account and monitor ID. Treat 429 as a temporary request limit. Read the response Retry-After header and pause for the supplied duration before retrying. Do not change the audit conclusion.

Approve One Account Monitor Change

Fetch the monitor immediately before an approved update. Store its monitor ID, username, and stable X user ID. Add event types, active state, and billing schedule. This snapshot becomes the change baseline. Confirm the target profile first. Usernames can change. The stable xUserId prevents a renamed profile from looking like another account. Stop when the requested profile does not match the stored target. Review existing and proposed eventTypes together. List every added and removed account event. Check whether existing webhooks accept the proposed types. Update webhook subscriptions before relying on new alerts. Read isActive separately from event configuration. A pause keeps the target and event types. A resume restores polling under the stored contract. Record the previous state before toggling it. After the update, fetch the same monitor ID again. Compare its target, event types, active state, and nextBillingAt. Keep both snapshots with the approved change ticket. This proves the exact account-monitor change.

Trace One Missing Profile Alert

Start with the monitor ID from the affected workflow. Confirm its username and stable X user ID. Then verify the expected event type exists. Check isActive during the missing-alert window. A paused monitor does not create future account events. Check nextBillingAt and available credits when monitoring should continue. Query stored events with monitorId. Separate an absent event from an absent webhook delivery. Open the matching event before inspecting receiver attempts. For delivery review, join the event ID with delivery streamEventId. Keep deliveryId as the attempt identity. Do not join through an X Tweet ID. Record one diagnosis outcome. The monitor may target the wrong profile. It may omit the event type or remain paused. It may lack a stored event. The webhook delivery may fail. Those outcomes require different fixes.

Path parameters

string
required
The unique monitor ID. Returned when you create a monitor or list monitors.

Headers

string
required
Your API key. Session cookie authentication is also supported. Generate a key from the dashboard.

Response

200 OK

string
Unique monitor ID.
string
Normalized X username.
string
Resolved X user ID.
string[]
Subscribed event types.
boolean
Indicates whether monitoring continues.
string
Creation time in ISO 8601 format.
string
Next hourly credit charge time for active monitor billing.

400 Invalid ID

The provided monitor ID is not a valid format.

401 Unauthenticated

Missing or invalid API key.

404 Not Found

No monitor exists with this ID, or it belongs to a different account.

429 Rate Limited

Too many requests. Wait for the Retry-After header before retrying.
Related: List Monitors to see all monitors, List Events to audit stored events, List Deliveries to audit webhook delivery status, Update Monitor to change event types or toggle active status, or Delete Monitor to remove this monitor.