Monitors
Twitter Account Activity Tracker & Monitor Status
Check one Twitter account activity tracker for its X profile, tweet and profile event filters, active alert state, billing, events, and webhook deliveries.
- 200
- 400
- 401
- 404
- 429
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
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
UseGET /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 bothusername 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 thateventTypes 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 stablexUserId. 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. Storeid, 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 stablexUserId
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. CheckisActive 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
401 Unauthenticated
404 Not Found
429 Rate Limited
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.
- 200
- 400
- 401
- 404
- 429
Twitter Account Activity Tracker & Monitor Status