Monitors
Twitter account monitoring list & tracked profiles
List Twitter account monitors with tracked X profiles, tweet and profile event filters, active states, creation times, and billing checkpoints per monitor.
- 200
- 401
- 429
GET
Twitter account monitoring list & tracked profiles
Inventory every Twitter account monitor
UseGET /monitors to monitor multiple Twitter accounts.
It returns one complete account-monitor inventory.
The route lists every account monitor that belongs to the signed-in user. Each
row identifies one tracked X profile. It also shows enabled tweet or profile
events and the active state. The row includes its creation time. Check
nextBillingAt for the next active-monitor charge. Use the single-monitor
route for one known ID.
Group rows by username or stable xUserId. Keep eventTypes with every row
because two monitors can track different changes. Separate inactive monitors
before calculating which profiles still produce events.
Store monitorId before handing a row to event or webhook processing. Event
queries use that ID to isolate tweets and profile changes. Webhook deliveries
remain separate from monitor inventory.
Review nextBillingAt before enabling more monitors. Listing is free, but
active monitors consume credits each hour. Delete unused monitors. Do not call
a monitor idle after one empty event window.
Free - does not consume credits
How do you monitor multiple Twitter accounts?
Create one account monitor for each X username. Select only the required tweet and profile event types. Then call this route to rebuild the complete list. Store each returnedid as the stable monitor key. Keep xUserId beside the
username because an account can change its username.
This inventory supports Twitter account monitoring across many tracked
profiles. Use isActive to filter rows before estimating costs.
Group active rows by owner, workflow, or webhook receiver. Keep paused rows in
the same inventory because their configuration still exists.
Use List Events to retrieve stored events for one
monitor. Pass the returned monitor ID as monitorId. Use
List Webhooks to inspect receivers. Use
List Deliveries to audit each delivery.
This route lists monitor settings, not stored events.
What does the monitor inventory include?
Each row shows the monitor ID, username, and stable X user ID for account joins. TheeventTypes array defines which tweet and profile changes matter.
The isActive field separates running monitors from paused configurations.
The timestamps show when Xquik created the monitor and its next billing point.
Tweet filters cover new posts, replies, quotes, reposts, media, and links. They
also cover polls, mentions, hashtags, and long-form posts. Profile filters
include the avatar, banner, name, username, biography, and location. They also
cover URL, verification, protection, pinned tweets, and account availability.
Read eventTypes from every row. Do not assume every monitor uses identical
filters.
The response also includes total. Compare it with the emitted monitor count.
A mismatch usually means the client dropped rows during local processing. The
route returns up to 200 monitors and does not paginate. Treat one successful
response as the complete server result for that request.
Does this route return tweets or analytics?
No.GET /monitors returns account-monitor configurations. It does not return
tweet timelines, engagement totals, audience reports, or sentiment scores.
Use List Events for stored tweet and profile
events. Use Get Event to inspect one stored event.
The route also does not publish or schedule posts. Use the
X Write API for publishing workflows.
Keep these responsibilities separate. Otherwise, a monitor inventory can
become an event feed or publishing queue.
How do you set alerts for several X accounts?
First, create one monitor per username. Give each monitor only the event types its receiver understands. Then create a webhook for the matching event types. Store the monitor ID with every workflow rule. This preserves the source when several profiles send similar events. Re-list monitors after every create, update, pause, or delete operation. Check that the intended row exists and has the expectedeventTypes. Confirm
isActive before waiting for a new alert. Paused monitors retain their
settings. They stop polling until reactivated.
Audit webhook deliveries separately. Join a delivery to its stored event with
the documented event ID. Do not infer success from the monitor’s active state.
Polling state and webhook delivery status are separate.
How should teams manage many tracked profiles?
Assign one owner when managing multiple Twitter accounts. Store that owner outside the API response. Save the monitor ID, X user ID, selected event types, and active state. Add the owner and review date. Assign ownership by workflow. Support teams can process replies and mentions. Research teams can own new posts, quotes, or media events. Account teams can own profile-name, biography, verification, or availability changes. Match each assignment to the exacteventTypes returned for that monitor.
Agencies should separate client profiles before reporting active-monitor
costs. Review paused and active rows together, but count their costs
separately. Record every approved state change. This history prevents one
client cleanup from changing another client’s monitor.
Is listing Twitter account monitors free?
Yes. ThisGET request consumes no credits. Active monitors cost 21 credits
per monitor-hour. Paused monitors stay listed and stop active-monitor billing.
Review isActive and nextBillingAt before enabling more profiles.
Do not use a quiet event window as a cost signal. A valid monitor may receive
no matching event during that period. Confirm its owner and selected filters
before pausing it. Delete a monitor only when its configuration is no longer
required.
Inventory handoff
UseGET /monitors after create, update, pause, or delete operations to rebuild
your account monitor inventory. The response returns up to 200 monitors ordered
by creation time and a total count for the returned set.
Tracked accounts
Store each monitor’s
id, username, and xUserId with downstream CRM,
warehouse, or queue records.Detail handoff
Use Get Monitor with each
id when a
support workflow needs the latest event filter, active state, or billing
checkpoint for one account monitor.Active billing
Filter monitors where
isActive is true. Each active account monitor
bills 21 credits per active monitor-hour; use nextBillingAt to schedule
credit checks or pause stale alerts.Webhook alignment
Compare each monitor’s
eventTypes with List Webhooks
before relying on signed alerts.Event backfill
Use
id as monitorId with List Events to
audit stored account monitor events. Open one returned ID with
Get Event to inspect the complete stored event.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.State repair
Use Update Monitor to replace
eventTypes
or toggle isActive. Use Delete Monitor
only when the tracked account should stop permanently.Reconcile an account monitor inventory
Store one row per monitor ID. Include its username, X user ID, and event types. Add the active state and billing date. Join monitors to webhooks by configured ownership. Flag missing webhooks, extra webhooks, and mismatched event types. Compare completed snapshots to identify new, paused, resumed, or removed monitors. Do not compare partially paginated inventories. Use the single-monitor route for an incident review. Update only the monitors approved for change.Assign account monitor ownership
Use the complete list to assign every tracked X profile. Start with monitor ID,username, and stable xUserId. Keep the stable ID when a username changes.
Group rows by the team consuming their events. Support teams may own reply and
mention events. Research teams may own new posts. Account operations may own
profile changes. Store ownership outside returned API fields.
Compare eventTypes with each receiver contract. A webhook receiving only
tweet events cannot process a profile biography change. Flag missing
subscriptions before calling the monitor healthy.
Then inspect active state. Active monitors can produce new account events.
Paused monitors preserve configuration without polling. Keep both groups in
the inventory. Never treat a paused row as deleted.
Use nextBillingAt for active-budget reviews. Listing remains free. Count
active account monitors separately from keyword monitors. Their targets and
event contracts serve different workflows.
Publish one ownership row per monitor ID. Include username, X user ID, event
types, active state, and billing checkpoint. Add its owner and review date.
This record makes later account-monitor changes explicit.
Prepare safe bulk account monitor cleanup
Begin from one complete list response. Do not combine partial snapshots. Mark rows lacking an owner, current workflow, or required webhook subscription. Inspect recent stored events before proposing a pause. An empty window does not prove the profile is irrelevant. Confirm the account, event types, and review window with the owner. Pause monitors through the update route first. Keep their IDs and previous event types in the change record. Observe receiver queues before permanent deletion. Delete only approved rows. Re-list monitors after every batch. Confirm removed IDs are absent and paused IDs remain present. Record billing checkpoints for the remaining active rows. Handle uncertain changes individually. Use the single-monitor status route for each affected ID. Never replay a bulk delete because the client lost its local response.Headers
string
required
Your API key. You can also sign in with a session cookie. Create a key from the dashboard.
Response
200 OK
object[]
Array of monitor objects.
string
Unique monitor ID.
string
Normalized X username.
string
Resolved X user ID.
string[]
Subscribed event types.
boolean
Whether the monitor is currently active.
string
ISO 8601 creation timestamp.
string
Next hourly credit charge time for active monitor billing.
number
Total number of monitors.
401 Missing API key
429 Rate limited
Retry-After header before retrying.
Returns up to 200 monitors. There is no pagination. Contact support if you need more.
Related. Create Monitor to add a new monitor, Get Monitor to fetch one monitor, List Events to audit stored events, Get Event to inspect one event, List Webhooks to compare subscriptions, or List Deliveries to audit webhook delivery status.
- 200
- 401
- 429
Twitter account monitoring list & tracked profiles