Monitors
Twitter keyword monitor API & real-time tweet alerts
Create a 1-second keyword monitor for an X search query. Store matching tweet events and deliver selected events to signed webhooks. Costs 21 credits/hour.
- 201
- 400
- 401
- 402
- 409
- 429
POST
Twitter keyword monitor API & real-time tweet alerts
Create a Twitter keyword monitor when one search query needs continuous tweet checks. Track brand mentions, handles, hashtags, products, campaigns, replies, reposts, links, or media. Store its ID, query, event types, billing time, and webhook destinations.
The cURL, Node.js, and Python examples convert the created or reactivated
keyword monitor into one state row. Store
Active keyword monitors check every 1 second and cost 21 credits per active monitor-hour. Creation or reactivation requires 22 available credits. Pause with Update Keyword Monitor and
Missing query, query longer than 512 characters, or invalid
Missing or invalid API key.
You need at least 22 available credits to create or reactivate an active keyword monitor. Possible errors include
An active keyword monitor already exists for this normalized query. Use Update Keyword Monitor to change event types or pause it.
Too many requests. Wait for the
Requires 22 available credits. Active keyword monitors bill 21 credits per hour.
Keyword monitors are unlimited. Active monitors check every 1 second. Active monitor billing includes webhook and event deliveries.
keyword_monitor_id, query,
event_types, is_active, next_billing_at, verify_endpoint,
update_endpoint, delete_endpoint, events_endpoint,
event_detail_endpoint_pattern, webhooks_endpoint, and
deliveries_endpoint_pattern before routing alerts.
Keyword monitor handoff
UsePOST /monitors/keywords when a queue, CRM, warehouse, Slack alert, or agent
needs 1-second checks for one X search query. Create the monitor first. Then
create a signed webhook with
POST /webhooks. Test it with
POST /webhooks/{id}/test.
Monitor ID
Store
id as keyword_monitor_id. Use
Get Keyword Monitor to verify state,
Update Keyword Monitor to pause or
resume, and Delete Keyword Monitor
only when the query should stop permanently.Normalized query
Store
query. Xquik includes it on keyword monitor events and signed
webhook payloads.Event filter
Store
eventTypes. Keep List Webhooks
subscriptions aligned so expected tweets deliver.Active state
Read
isActive and nextBillingAt before enabling alerts or estimating
hourly monitor cost.Stored event join
Use
monitorType: "keyword", keywordMonitorId, and query from
List Events to join stored events back to the
monitor. Use Get Event for one event’s full
payload.Webhook delivery join
Use
deliveryId for receiver idempotency and
List Deliveries for delivery audit
rows. Join delivery streamEventId to event IDs. Do not use x_event_id as
the delivery join key.{ "isActive": false } when the alert should stop.
How do I monitor Twitter keywords with an API?
Use one focused query for each alert purpose. First, write the exact words, phrases, handles, or hashtags requiring alerts. Then select the tweet event types your workers need. Create the monitor and store its returned ID. Next, connect a signed webhook for the selected event types. Send a signed test before accepting production alerts. Store each event before returning a successful receiver response. Use the event ID and delivery ID for separate idempotency checks. Your application needs no open stream connection. The Twitter keyword monitor checks its stored query every second. Matching tweets become stored events and signed webhook deliveries. Use List Events when a webhook consumer needs recovery.How do I choose Twitter keywords to monitor?
Start with terms that lead to one action. Support teams can watch product names, error phrases, or direct handles. Campaign teams can watch campaign hashtags and reply language. Developers can watch API names, integration phrases, or release mentions. Prefer an exact phrase when word order changes meaning. UseOR when any listed term should match.
Use a space when every listed term must appear.
Use a leading minus sign to exclude known noise.
Group mixed OR conditions with parentheses.
For example, monitor direct mentions with @xquik.
Monitor a phrase with "x api".
Combine related terms with (@xquik OR "xquik api").
Exclude reposts with -is:retweet when repost alerts add no value.
Test the proposed query with Search Tweets first.
Review returned tweets before enabling continuous keyword monitoring.
Narrow irrelevant matches before paying for an active monitor.
Never add undocumented operators to widen coverage.
How do I track Twitter mentions and brand keywords?
Include the exact handle when direct mentions require action. Add the brand name when plain-text mentions also matter. Add specific product names only when workers own those alerts. Keep unrelated brands in separate monitors and queues. For every matched tweet, store the tweet ID, author ID, event type, query, and timestamp. KeepkeywordMonitorId beside each stored event.
This join shows which query matched the tweet.
The selected query monitors conversations across public matching tweets.
It does not calculate sentiment or brand reputation.
It also cannot reveal private tweets or direct messages.
A match shows that a tweet contains your terms. It does not show opinion.
When should I use keyword alerts, tweet search, or account monitoring?
Choose the option that matches the required time range and scope.
Do not mix these 3 scopes in one tool.
Use Twitter search for backfill and investigation.
Use an account monitor for one known profile.
Use keyword alerts for continuous matches across public tweets.
Brand monitoring often needs both keyword and account monitors.
Keep their event IDs, monitor IDs, and queue routes separate.
Workers can then tell which source produced each alert.
How do real-time tweet alerts reach my application?
Create the keyword monitor before registering its webhook destination. Subscribe the webhook to the same selected event types. Then send a signed test to validate the receiver. Verify every signature before parsing the request body. StoredeliveryId before you queue work.
Store streamEventId before processing the matching tweet.
Return success only after the queue write completes.
The Events API provides recovery when live delivery fails.
The Deliveries API shows webhook attempts for one registered endpoint.
Use Webhook Verification for receiver validation.
Use List Deliveries for delivery audits.
API access errors require different recovery actions.
Replace invalid credentials after a 401 response.
Add credits before retrying a 402 response.
Respect Retry-After before repeating a 429 request.
How do I backfill tweets before starting keyword monitoring?
Run the same query through Search Tweets before creating the monitor. Page until the response reports no next page. Store every tweet ID and its source query. Record the newest collected tweet timestamp as the handoff boundary. Then create the keyword monitor with the reviewed query. Deduplicate backfill and monitor events by stable tweet ID. Keep the stored monitor ID beside every continuous event. Do not reuse a search cursor after changing the query. Keep historical results separate from live alerts. Search results answer an on-demand time range. Monitor events represent continuous checks after activation. Combining both sources without a boundary creates duplicate tweets.How do I monitor multiple keyword groups?
Use one monitor when all terms share one alert action. Combine those terms with explicitOR grouping.
Use separate monitors when terms require different owners or queues.
Separate monitors also keep distinct query evidence.
Store each monitor ID, normalized query, event types, and billing time.
Pause obsolete monitors instead of creating uncertain duplicates.
List keyword monitors before repeating a timed-out create request.
A paused duplicate can reactivate with the submitted event types.
Review active monitors before each billing checkpoint.
Every active keyword monitor adds its hourly charge.
Pause queries that no longer trigger an action.
Do not broaden queries to generate more alerts.
How do I keep Twitter keyword alerts actionable?
Assign one owner and queue to each monitor ID. Route alerts by query, event type, and matched tweet ID. Keep support alerts separate from campaign or competitor alerts. Define the required action before activating the monitor. Review false matches from stored events at a regular interval. Add exact phrases or exclusions when irrelevant tweets repeat. Remove a term when nobody acts on its alerts. Keep the previous query beside every configuration change. Do not delete evidence when a query changes. Stored events explain why earlier alerts reached their original queue. Record the change time and the responsible operator. Use a new monitor when the owner or alert purpose changes. Measure matched tweets, accepted alerts, rejected alerts, and processing failures. Those counts show how precise the query is. Pause noisy monitors while operators correct their stored queries. Resume only after a reviewed search returns useful tweets.What does a Twitter keyword monitor not provide?
A keyword monitor does not return a complete historical archive. It does not provide follower, following, like, or bookmark changes. It does not verify giveaway follows, replies, or reposts by itself. It does not calculate sentiment, reach, or engagement quality. Use Followers for follower snapshots. Use Following for following snapshots. Use focused tweet endpoints for replies, quotes, and retweeters. Use Search Tweets when an operator needs historical matching tweets. This endpoint tracks one query and delivers matches to webhooks. It stores matched tweets. It infers nothing about them.Headers
string
required
Your API key. Session cookie authentication is also supported. Generate a key from the dashboard.
string
required
Must be
application/json.Body
string
required
X search query to monitor. Xquik normalizes whitespace. Maximum length is 512 characters.
string
Your own label for the monitor, 1 to 80 characters. Every event the monitor produces carries it as
monitorName, so you can route events from the payload. Xquik normalizes whitespace.string[]
required
Array of event types to subscribe to. At least 1 required. See Valid Event Types below.
Valid event types
Valid keyword monitor types:tweet.new, tweet.quote, tweet.reply,
tweet.retweet, tweet.media, tweet.link, tweet.poll, tweet.mention,
tweet.hashtag, tweet.longform.
tweet.new
Matching tweet returned by the query. Xquik uses it when no reply, quote,
or retweet signal is present.
tweet.quote
Matching quote tweet returned by the query. Include this when quote
activity should create keyword monitor events and webhook deliveries.
tweet.reply
Matching reply returned by the query. Include this when support routing,
conversation tracking, or alerting needs replies.
tweet.retweet
Matching retweet returned by the query. Include this when repost activity
should create keyword monitor events and webhook deliveries.
Response
201 Created
string
Unique keyword monitor ID.
string
Normalized query being monitored.
string[]
Event types this monitor is subscribed to.
boolean
Whether the monitor is active.
string
ISO 8601 creation timestamp.
string
Next hourly credit charge time. New active monitors are due immediately.
400 Invalid input
eventTypes.
401 Unauthenticated
402 Payment required
no_credits and insufficient_credits.
409 Duplicate
429 Rate limited
Retry-After header before retrying.
If a keyword monitor for the same query exists but is paused, creating it again reactivates that monitor with the new event types.