Skip to main content
GET
Twitter account monitoring list & tracked profiles

Inventory every Twitter account monitor

Use GET /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 returned id 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. The eventTypes 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 expected eventTypes. 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 exact eventTypes 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. This GET 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.
The Node.js, Python, and Go examples emit one structured monitor record. Save each record with its support, event, and webhook audit history.

Inventory handoff

Use GET /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

Missing or invalid API key.

429 Rate limited

Too many requests. Wait for the 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.