Skip to main content
POST
Twitter account monitor API & real-time webhooks
Create a Twitter account monitor for one known profile. Select tweet, profile, or availability events. Store the monitor ID. Then connect signed webhooks.
Requires 22 available credits. The username lookup costs 1 credit. The first active monitor hour costs 21 credits.
Monitors are unlimited. Active monitors check every 1 second. Webhook and event deliveries are included in active monitor billing.

Create a Twitter monitor for one account

Use this Twitter monitor API for continuous checks on one known profile. Send the username without @. Choose only the required event types. This API endpoint gives you one stable monitor ID. Use it to join events and webhook deliveries. Use POST /monitors for Twitter API monitoring from one username. This tweet monitor covers selected posts, replies, quotes, reposts, and profile changes. It does not search posts from every public account.

Choose the right Twitter monitoring option

Choose one option for the required alert scope. Do not replace one option with another after collection starts. Store the chosen monitor type beside every downstream alert.

How do I monitor a Twitter account with an API?

Create one active monitor for each username requiring continuous checks. Send the username without @ and choose exact event types. Xquik resolves the username to one stable X user ID. Store both the monitor ID and resolved user ID. Teams can monitor Twitter account activity without maintaining a stream connection. The account monitor checks selected changes every second. Real-time Twitter alerts start after connecting a signed webhook. Stored events remain available for later inspection through the Events API. Use the monitor ID for updates, pauses, deletion, and event joins. Use the X user ID for stable account joins. Never use a display name as the account key.

Which Twitter account activity can trigger alerts?

Select tweet.new for original posts from the monitored account. Add tweet.reply, tweet.quote, or tweet.retweet for conversation activity. Use format events for media, links, polls, mentions, hashtags, and long posts. Each selected event type creates a focused alert stream. Profile events cover names, usernames, bios, locations, URLs, avatars, and banners. They also cover verification, protection, pinned posts, and account availability. Use profile.unavailable.changed when account availability affects a workflow. Keep previous and current profile values with the stored event. Choose only events that trigger a real downstream action. Extra event types create alerts that workers must still review. Update the monitor when the required event set changes. Do not infer unselected changes from tweet or profile counts.

How do real-time Twitter alerts reach my application?

Create the account monitor before registering its delivery endpoint. Then create an HTTPS webhook with the required event filters. Save the one-time webhook secret in a secret manager. Send a signed test before accepting production deliveries. Verify X-Xquik-Signature, X-Xquik-Timestamp, and X-Xquik-Nonce first. Compute the signature from the raw request body. Reject invalid signatures before parsing or queuing the payload. See Webhook Verification for complete receiver examples. Use deliveryId for delivery-level idempotency. Use streamEventId for one-time monitor event processing. Store the queue row before returning a successful receiver response. Inspect Webhook Deliveries when alerts stop arriving.

How do I monitor competitor Twitter account activity?

Create one account monitor for each competitor username. Track new tweets, replies, quotes, reposts, links, and media. Add profile events for bio, username, avatar, banner, and pinned-post changes. Store each event type, timestamp, monitor ID, and X user ID. This workflow records concrete account changes. It does not calculate sentiment, brand reputation, or share of voice. Use a keyword monitor for mentions across unrelated accounts. Use tweet search for a retrospective competitor query. Keep competitor alerts separate from your own account alerts. Route each monitor ID to its intended queue or workspace. That separation prevents one competitor event from triggering unrelated jobs.

How do I monitor multiple Twitter accounts?

Create one monitor request per username. Monitors are unlimited, but each active monitor has hourly billing. Keep at least 22 credits before creating or restoring each monitor. Store every returned monitor ID before creating the next request. An active duplicate returns 409 monitor_already_exists. Use List Monitors to recover its stored ID. Use Update Monitor to change events or active state. Do not create replacement monitors when a pause is sufficient. Store each resolved X user ID beside the current username. This join remains stable when a username-change event arrives. Review nextBillingAt before keeping large monitor sets active.

What does an account monitor not track?

Account monitors do not emit follower-gained or follower-lost events. They also exclude likes, bookmarks, and direct-message activity. They do not return a complete historical timeline. They do not search specific keywords across every account. Use Followers for paginated follower snapshots. Use Following for paginated following snapshots. Use User Tweets for timeline retrieval. Use Create Keyword Monitor for matching queries. Never substitute aggregate counts for missing participant or relationship records. Choose the endpoint that returns the required tweets, profiles, or relationships.

How do I recover from monitor and webhook failures?

List account monitors before repeating an uncertain create request. Reuse the stored monitor when the first request succeeded. Retry the same username and event types only when no monitor exists. Correct invalid usernames or event arrays after a 400 response. Replace missing credentials after 401 authentication errors. Add credits before retrying a 402 insufficient_credits response. Check the username after a 404 user_not_found response. Reuse the existing monitor after a 409 duplicate response. Respect Retry-After before repeating a 429 request. Webhook failures do not require replacing a healthy monitor. Fix the receiver, verify its signature code, and send another signed test. Then inspect delivery attempts and join streamEventId to the stored event.
Each code example maps the response to one monitor row. Save the account IDs, event filter, active state, next charge time, and monitor routes. The routes cover updates, events, webhooks, and delivery checks.

Account monitor handoff

Use POST /monitors for one X account. Send alerts to a queue, CRM, warehouse, Slack, or an agent. It checks selected tweets and profile changes every second. Create the monitor first. Then create a signed webhook with POST /webhooks. Call POST /webhooks/{id}/test before enabling production alerts.

Monitor ID

Store id as monitor_id. Verify state with Get Monitor. Pause or resume with Update Monitor. Call Delete Monitor only when tracking should stop permanently.

Stored account

Store username after trimming the @ prefix. Store xUserId for stable joins, dedupe, and downstream account mapping.

Event filter

Store eventTypes; keep List Webhooks subscriptions aligned so expected account activity delivers.

Active state

Read isActive and nextBillingAt before enabling alerts or estimating hourly monitor burn.

Stored event join

Read monitorType: "account", monitorId, and username from List Events. Use them to join stored events to the account. Use Get Event for one event.

Webhook delivery join

Use deliveryId for receiver idempotency and List Deliveries for delivery attempts. Join streamEventId to event IDs; do not use x_event_id as the delivery join key. Store eventType, occurredAt, and data with the downstream job.

What should a webhook receiver save?

Save the monitor ID, username, user ID, event type, event time, and delivery ID. Use the monitor ID to group alerts for one account. Use the delivery ID to stop the same job twice. Keep the event ID for later checks. These fields help with replay, audits, retries, and clear alert ownership. Active account monitors check every 1 second. Each active hour costs 21 credits. You need 22 available credits to create or restore a monitor. That total includes a 1-credit username lookup and the first active hour. Pause the monitor through Update Monitor (PATCH /monitors/{id}). Set { "isActive": false } when alerts should stop.

Headers

string
required
Send your Xquik API key. Create one in the Xquik dashboard.
string
Send Bearer <token> instead of x-api-key when using OAuth 2.1.
string
required
Must be application/json.

Body

string
required
Send an X username with 1-15 letters, numerals, or underscores. Xquik removes a leading @ before validation.
string[]
required
Array of event types to subscribe to. At least 1 required. See Valid Event Types below.

Valid event types

Choose only the exact event types in the goal map below.

Match event types to monitor goals

Account monitors do not emit follower-gained or follower-lost events. Use Followers and Following for paginated relationship snapshots.

tweet.new

Original tweet from the monitored account. Used when no reply, quote, or retweet signal is present.

tweet.quote

Quote tweet from the monitored account. Include this when quote activity should create stored events and webhook deliveries.

tweet.reply

Reply from the monitored account. Include this when support routing, conversation tracking, or alerting needs replies.

tweet.retweet

Retweet from the monitored account. Include this when repost activity should create stored events and webhook deliveries.

Response

201 Created

string
Unique monitor ID.
string
Stored X username after trimming and removing the @ prefix.
string
Resolved X user ID for the account.
string[]
Event types this monitor is subscribed to.
boolean
Whether the monitor is currently active.
string
Xquik records the creation time in ISO 8601 format.
string
Next hourly credit charge time. New active monitors are due immediately.

400 Invalid input

Invalid username format or missing/invalid eventTypes array.

401 Missing API key

Missing or invalid API key or OAuth bearer token.

402 Payment required

Keep at least 22 credits available before sending this request. The API may return insufficient_credits when the balance is too low.

404 User not found

Xquik could not find that username. Check the spelling.

409 Duplicate

An active monitor already tracks this X account. Use Update Monitor to change event types instead.

429 Rate limited

Too many requests. Wait for the Retry-After header before retrying.
A previously deleted monitor is reactivated with new event types. An active duplicate returns 409.
Next steps.