> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xquik.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 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.
For the complete documentation index, see llms.txt.
## 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.** This endpoint does not consume credits.
```bash cURL theme={null}
curl -X GET https://xquik.com/api/v1/monitors/7 \
-H "x-api-key: xq_YOUR_KEY_HERE" \
| jq '{
monitor_id: .id,
username: .username,
x_user_id: .xUserId,
event_types: .eventTypes,
is_active: .isActive,
created_at: .createdAt,
next_billing_at: .nextBillingAt,
update_endpoint: ("/api/v1/monitors/" + .id),
events_endpoint: ("/api/v1/events?monitorId=" + .id),
event_detail_endpoint_pattern: "/api/v1/events/{event_id}",
webhooks_endpoint: "/api/v1/webhooks",
deliveries_endpoint_pattern: "/api/v1/webhooks/{webhook_id}/deliveries"
}'
```
```javascript Node.js theme={null}
const monitorId = "7";
const response = await fetch(`https://xquik.com/api/v1/monitors/${monitorId}`, {
method: "GET",
headers: {
"x-api-key": "xq_YOUR_KEY_HERE",
},
});
const monitor = await response.json();
const monitorState = {
monitor_id: monitor.id,
username: monitor.username,
x_user_id: monitor.xUserId,
event_types: monitor.eventTypes,
is_active: monitor.isActive,
created_at: monitor.createdAt,
next_billing_at: monitor.nextBillingAt,
update_endpoint: `/api/v1/monitors/${monitor.id}`,
events_endpoint: `/api/v1/events?monitorId=${monitor.id}`,
event_detail_endpoint_pattern: "/api/v1/events/{event_id}",
webhooks_endpoint: "/api/v1/webhooks",
deliveries_endpoint_pattern: "/api/v1/webhooks/{webhook_id}/deliveries",
};
process.stdout.write(`${JSON.stringify(monitorState)}\n`);
```
```python Python theme={null}
import json
import requests
monitor_id = "7"
response = requests.get(
f"https://xquik.com/api/v1/monitors/{monitor_id}",
headers={"x-api-key": "xq_YOUR_KEY_HERE"},
)
monitor = response.json()
monitor_state = {
"monitor_id": monitor["id"],
"username": monitor["username"],
"x_user_id": monitor["xUserId"],
"event_types": monitor["eventTypes"],
"is_active": monitor["isActive"],
"created_at": monitor["createdAt"],
"next_billing_at": monitor["nextBillingAt"],
"update_endpoint": f"/api/v1/monitors/{monitor['id']}",
"events_endpoint": f"/api/v1/events?monitorId={monitor['id']}",
"event_detail_endpoint_pattern": "/api/v1/events/{event_id}",
"webhooks_endpoint": "/api/v1/webhooks",
"deliveries_endpoint_pattern": "/api/v1/webhooks/{webhook_id}/deliveries",
}
print(json.dumps(monitor_state))
```
```go Go theme={null}
package main
import (
"encoding/json"
"log"
"net/http"
"os"
)
type Monitor struct {
ID string `json:"id"`
Username string `json:"username"`
XUserID string `json:"xUserId"`
EventTypes []string `json:"eventTypes"`
IsActive bool `json:"isActive"`
CreatedAt string `json:"createdAt"`
NextBillingAt string `json:"nextBillingAt"`
}
type MonitorState struct {
DeliveriesEndpointPattern string `json:"deliveries_endpoint_pattern"`
EventDetailEndpointPattern string `json:"event_detail_endpoint_pattern"`
EventsEndpoint string `json:"events_endpoint"`
EventTypes []string `json:"event_types"`
CreatedAt string `json:"created_at"`
IsActive bool `json:"is_active"`
MonitorID string `json:"monitor_id"`
NextBillingAt string `json:"next_billing_at"`
UpdateEndpoint string `json:"update_endpoint"`
Username string `json:"username"`
WebhooksEndpoint string `json:"webhooks_endpoint"`
XUserID string `json:"x_user_id"`
}
func main() {
monitorID := "7"
req, err := http.NewRequest("GET", "https://xquik.com/api/v1/monitors/"+monitorID, nil)
if err != nil {
log.Fatal(err)
}
req.Header.Set("x-api-key", "xq_YOUR_KEY_HERE")
resp, err := http.DefaultClient.Do(req)
if err != nil {
log.Fatal(err)
}
defer resp.Body.Close()
var monitor Monitor
if err := json.NewDecoder(resp.Body).Decode(&monitor); err != nil {
log.Fatal(err)
}
state := MonitorState{
DeliveriesEndpointPattern: "/api/v1/webhooks/{webhook_id}/deliveries",
EventDetailEndpointPattern: "/api/v1/events/{event_id}",
EventsEndpoint: "/api/v1/events?monitorId=" + monitor.ID,
EventTypes: monitor.EventTypes,
CreatedAt: monitor.CreatedAt,
IsActive: monitor.IsActive,
MonitorID: monitor.ID,
NextBillingAt: monitor.NextBillingAt,
UpdateEndpoint: "/api/v1/monitors/" + monitor.ID,
Username: monitor.Username,
WebhooksEndpoint: "/api/v1/webhooks",
XUserID: monitor.XUserID,
}
if err := json.NewEncoder(os.Stdout).Encode(state); err != nil {
log.Fatal(err)
}
}
```
The Node.js, Python, and Go examples produce one normalized monitor snapshot.
Store `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
Use `GET /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`.
| Account monitor status column | Response source | Decision rule |
| - | - | - |
| Monitor ID | `id` | Use this ID for updates, events, and deletion. |
| X username | `username` | Confirm the intended tracked profile. |
| X user ID | `xUserId` | Use this stable ID for account verification. |
| Event filter | `eventTypes` | Align webhook subscriptions before enabling alerts. |
| Polling state | `isActive` | Decide whether checks and billing should continue. |
| Creation time | `createdAt` | Record when Xquik created the monitor. |
| Billing checkpoint | `nextBillingAt` | Review credits before the next active charge. |
Treat `username` and `xUserId` as the resolved X account identity. Store
both with your CRM, warehouse, or queue records.
`eventTypes` decides which changes match. Copy those event
types into webhook subscriptions before relying on signed alerts.
Use `isActive` to decide whether the monitor should poll and bill. Use
[Update Monitor](/api-reference/monitors/update) to pause or resume it.
Use `id` as `monitorId` with [List Events](/api-reference/events/list) to
reconcile stored events and webhook deliveries for this account.
Use event IDs returned by [List Events](/api-reference/events/list) with
[Get Event](/api-reference/events/get) when a support, audit, or agent
workflow needs the full tweet payload.
Use [List Webhooks](/api-reference/webhooks/list) to compare webhook
`eventTypes` with this monitor before relying on signed alerts.
Use [List Deliveries](/api-reference/webhooks/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 both
`username` and `xUserId`. Keep the X user ID. It stays the same when a username changes.
`eventTypes` lists the changes the monitor matches now. 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](/api-reference/x/followers) at approved intervals. Use the
[follower export guide](/guides/follower-export-crm) 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 working account alert
needs 4 checks to pass.
| Alert layer | Status check | Required evidence |
| - | - | - |
| Tracked profile | `username` and `xUserId` | Both identify the intended X account. |
| Event filter | `eventTypes` | The expected tweet or profile event is selected. |
| Polling | `isActive` | The monitor was active during the expected change. |
| Delivery | Events and webhook deliveries | A stored event exists and the receiver accepted its delivery. |
First, confirm the tracked profile. Next, find the expected type in
`eventTypes`. Then verify `isActive`. Query
[List Events](/api-reference/events/list) with this monitor ID. Finally, join
the stored event to [webhook deliveries](/api-reference/webhooks/deliveries)
through `streamEventId`.
An active flag alone does not prove the alert works. The monitor may poll
correctly while a webhook fails. A webhook may also work while the monitor
omits the expected event type. Check configuration, events, and deliveries
separately.
## How do I track mentions and replies for one account?
Confirm that `eventTypes` 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](/api-reference/events/list) with `monitorId` after confirming
the filters. Filter stored events by the required type and time window. Open
the complete record through [Get Event](/api-reference/events/get). 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](/api-reference/events/list) returns cursor-based pages of stored
event records. Call [X user tweets](/api-reference/x/user-tweets) when an audit
requires recent profile posts. Use an extraction job for follower CSV exports.
Keep these outputs separate. A monitor status snapshot shows 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
stable `xUserId`. 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](/api-reference/events/list) to find changes captured by the
monitor. Open each event before making an activity claim. Use
[webhook deliveries](/api-reference/webhooks/deliveries) to verify receiver
attempts. None of these steps produce an analytics
report.
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. Store `id`, `username`, and
`xUserId`. Add `eventTypes`, `isActive`, `createdAt`, and `nextBillingAt`.
Together, these fields form one 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.changed`. 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. With these IDs, you can tell 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. Keep both snapshots
with the approved change ticket. Reject the update when `xUserId`
changes.
A `404` means the monitor does not exist or belongs to another account. 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 just before an approved update. Store its monitor ID,
username, and stable X user ID. Add event types, active state, and billing
schedule. Compare later snapshots against this one.
Confirm the target profile first. Usernames can change. The stable `xUserId`
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 restarts polling with the stored event types. 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. The 2 snapshots show what changed.
## 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.
Check `isActive` 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 delivery 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
The unique monitor ID. Returned when you [create a monitor](/api-reference/monitors/create) or [list monitors](/api-reference/monitors/list).
## Headers
Your API key. Session cookie authentication is also supported. Generate a key from the [dashboard](https://xquik.com/dashboard).
## Response
### 200 OK
Unique monitor ID.
Normalized X username.
Resolved X user ID.
Subscribed event types.
Indicates whether monitoring continues.
Creation time in ISO 8601 format.
Next hourly credit charge time for active monitor billing.
```json theme={null}
{
"id": "7",
"username": "elonmusk",
"xUserId": "44196397",
"eventTypes": ["tweet.new", "tweet.reply"],
"isActive": true,
"createdAt": "2026-02-24T10:30:00.000Z",
"nextBillingAt": "2026-02-24T11:30:00.000Z"
}
```
### 400 Invalid ID
```json theme={null}
{ "error": "invalid_id", "message": "Invalid ID format." }
```
The provided monitor ID is not a valid format.
### 401 Unauthenticated
```json theme={null}
{ "error": "unauthenticated", "message": "Missing or invalid API key" }
```
Missing or invalid API key.
### 404 Not found
```json theme={null}
{ "error": "not_found", "message": "Monitor not found" }
```
No monitor exists with this ID, or it belongs to a different account.
### 429 Rate limited
```json theme={null}
{
"error": "rate_limit_exceeded",
"message": "Too many requests. Try again later.",
"retryAfter": 1
}
```
Too many requests. Wait for the `Retry-After` header before retrying.
**Related.** [List Monitors](/api-reference/monitors/list) to see all monitors, [List Events](/api-reference/events/list) to audit stored events, [List Deliveries](/api-reference/webhooks/deliveries) to audit webhook delivery status, [Update Monitor](/api-reference/monitors/update) to change event types or toggle active status, or [Delete Monitor](/api-reference/monitors/delete-twitter-account-monitor) to remove this monitor.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.