> ## 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.
# Delete Twitter account monitor & stop monitoring
> Stop one Xquik account monitor and future checks. Xquik removes stored events in batches. Poll the status URL until it returns 404. The X account stays as is.
For the complete documentation index, see llms.txt.
This endpoint stops one account monitor immediately. It then removes stored
events and linked webhook deliveries in batches. The tracked X account
and its public data remain unchanged.
This operation is permanent. Pause the monitor when its alerts may resume.
**Free.** This endpoint does not consume credits.
```bash cURL theme={null}
curl -X DELETE https://xquik.com/api/v1/monitors/7 \
-H "x-api-key: xq_YOUR_KEY_HERE" |
jq -c '{
monitor_id: "7",
success: .success == true,
verify_endpoint: .statusUrl,
list_endpoint: "/api/v1/monitors",
events_endpoint: "/api/v1/events?monitorId=7",
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: "DELETE",
headers: {
"x-api-key": "xq_YOUR_KEY_HERE",
},
});
const result = await response.json();
const deletionReceipt = {
monitor_id: monitorId,
success: result.success === true,
verify_endpoint: result.statusUrl,
list_endpoint: "/api/v1/monitors",
events_endpoint: `/api/v1/events?monitorId=${monitorId}`,
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(deletionReceipt)}\n`);
```
```python Python theme={null}
import json
import requests
monitor_id = "7"
response = requests.delete(
f"https://xquik.com/api/v1/monitors/{monitor_id}",
headers={"x-api-key": "xq_YOUR_KEY_HERE"},
)
result = response.json()
deletion_receipt = {
"monitor_id": monitor_id,
"success": result["success"] is True,
"verify_endpoint": result["statusUrl"],
"list_endpoint": "/api/v1/monitors",
"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(deletion_receipt))
```
```go Go theme={null}
package main
import (
"encoding/json"
"log"
"net/http"
"os"
)
type DeleteResult struct {
StatusURL string `json:"statusUrl"`
Success bool `json:"success"`
}
type AccountMonitorDeletion struct {
MonitorID string `json:"monitor_id"`
Success bool `json:"success"`
VerifyEndpoint string `json:"verify_endpoint"`
ListEndpoint string `json:"list_endpoint"`
EventsEndpoint string `json:"events_endpoint"`
EventDetailEndpointPattern string `json:"event_detail_endpoint_pattern"`
WebhooksEndpoint string `json:"webhooks_endpoint"`
DeliveriesEndpointPattern string `json:"deliveries_endpoint_pattern"`
}
func main() {
monitorID := "7"
req, err := http.NewRequest(
"DELETE",
"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 result DeleteResult
if err := json.NewDecoder(resp.Body).Decode(&result); err != nil {
log.Fatal(err)
}
receipt := AccountMonitorDeletion{
MonitorID: monitorID,
Success: result.Success,
VerifyEndpoint: result.StatusURL,
ListEndpoint: "/api/v1/monitors",
EventsEndpoint: "/api/v1/events?monitorId=" + monitorID,
EventDetailEndpointPattern: "/api/v1/events/{event_id}",
WebhooksEndpoint: "/api/v1/webhooks",
DeliveriesEndpointPattern: "/api/v1/webhooks/{webhook_id}/deliveries",
}
if err := json.NewEncoder(os.Stdout).Encode(receipt); err != nil {
log.Fatal(err)
}
}
```
The examples store a deletion receipt. Poll `verify_endpoint` while it returns
`200`. Deletion finishes when it returns `404`. Respect `Retry-After` between
requests.
## Before you delete an account monitor
Delete only when the account monitor should never run again. Confirm the
monitor ID, X username, X user ID, and event types first.
Save required tweet and profile events before deletion. Record the approver and
final monitor identity in your own system.
Use keyword monitor deletion only for a keyword monitor. Keep other account and
keyword monitors when their checks must continue.
## Path parameters
The unique monitor ID.
## Headers
Your API key. Session cookie authentication is also supported. Generate a key from the [dashboard](https://xquik.com/dashboard).
## Response
### 202 Accepted
Returns `deleting` while cleanup runs.
Poll this URL until it returns `404`.
Always `true` when deletion starts.
```json theme={null}
{
"deletionStatus": "deleting",
"statusUrl": "/api/v1/monitors/7",
"success": true
}
```
The response includes `Location` and `Retry-After` headers. Poll `Location`
after the stated interval.
### 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": 60
}
```
Too many requests. Follow the `Retry-After` interval before another request.
## Does this delete the X account or its tweets?
No. This route deletes an Xquik account monitor only. This route cannot
deactivate X accounts. It does not remove tweets, followers, following,
replies, or likes. It also keeps reposts, media, lists, communities, and
profile details.
The tracked X account remains unchanged. Its public activity remains available
through the applicable X API endpoints. Xquik removes only its saved monitor and
related monitor records.
## Should I pause or delete account monitoring?
Pause when alerts may resume. Send `isActive: false` through [Update
Monitor](/api-reference/monitors/update). Pausing keeps the monitor ID,
profile, event filters, and stored history. It stops future checks, deliveries,
and hourly monitor billing.
Delete when monitoring will never resume. Deletion removes the saved
monitor and its stored history. A replacement monitor receives another ID.
| Decision | Use it when | Result |
| - | - | - |
| Pause | Account monitoring may resume. | Keeps the monitor and history. |
| Update filters | Only future tweet or profile coverage changes. | Replaces `eventTypes`. |
| Delete | The monitor and its history are no longer required. | Permanently removes both. |
## What does monitor deletion remove?
Deleting the monitor removes its settings and stored tweet events. It also
removes stored profile events, search records, and webhook delivery attempts.
These records depend on the deleted monitor.
Webhook endpoints remain configured. Existing endpoints can serve another
monitor with matching event subscriptions. Other account monitors and keyword
monitors remain active.
## How do I verify monitor deletion?
1. Save the monitor ID before sending `DELETE`.
2. Require `202` with `deletionStatus: "deleting"` and `success: true`.
3. Poll `statusUrl` until it returns `404 not_found`.
4. List monitors and confirm the ID is absent.
5. Treat another `DELETE` response of `404` as already removed.
A network timeout does not prove deletion. Confirm the monitor state
before another deletion request. Wait for `Retry-After` after a `429` response.
## Deletion handoff
Use this endpoint when a tracked account should stop permanently. Use
[Update Monitor](/api-reference/monitors/update) with `isActive: false` when
you only need to pause alerts and keep the monitor available.
| Account monitor deletion check | Source | Completion rule |
| - | - | - |
| Delete receipt | `deletionStatus`, `statusUrl`, `success` | Continue only after `202` with `success: true`. |
| Monitor inventory | `GET /monitors` | Confirm the deleted monitor ID is absent. |
| Detail lookup | `GET /monitors/{id}` | Expect `404 not_found` after deletion. |
| Stored events | `GET /events?monitorId={id}` | Save required tweet and profile events first. |
| Delivery history | `GET /webhooks/{id}/deliveries` | Keep required delivery evidence first. |
| Temporary stop | `PATCH /monitors/{id}` | Use `isActive: false` instead of deletion. |
## Plan retention before monitor deletion
Cleanup removes stored events and linked delivery records in batches.
Decide which records your team must keep before sending `DELETE`.
Export required tweet events and profile events first. Keep
each event's `id`, `type`, `monitorId`, `username`, and `occurredAt`. Keep
the complete `data` object for later tweet or profile processing.
Support teams may also need webhook delivery evidence. Save delivery status,
attempt counts, receiver responses, errors, and timestamps before deletion.
Store these records in your approved system. Never place API keys in exports.
Deletion does not create an archive. Xquik cannot return deleted monitor events
through the events endpoints later. Finish retention checks before approval.
## Select the exact Twitter account monitor
Never select a monitor from a display label alone. Read the account monitor and
compare its `id`, `username`, `xUserId`, `eventTypes`, and `isActive` values.
Use [List Monitors](/api-reference/monitors/list) when the monitor ID is
unknown. Then use [Get Monitor](/api-reference/monitors/twitter-account-monitor-status)
to confirm the selected record. Record the final identity beside the approval.
Delete account monitors and keyword monitors through their matching routes. Use
[Delete Keyword Monitor](/api-reference/monitors/delete-keyword) for a keyword
query. Never send a keyword monitor ID to this account monitor endpoint.
The route deletes by Xquik monitor ID. It does not delete by X username. One
account name then cannot select several monitor records.
## Keep tweet and profile events
Call [List Events](/api-reference/events/list) with the selected `monitorId`.
Follow every cursor until `hasMore` becomes `false`. Complete every cursor page
to include older tweet and profile events.
Use [Get Event](/api-reference/events/get) for every event needing full detail.
Keep `event.id` as the stable Xquik event identifier. Keep `event.type` to
separate tweet events from profile changes.
Store `occurredAt` with each event payload. It records when Xquik observed the
event. Keep the monitor ID with every exported row. You can then
reconcile rows after the monitor record disappears.
Validate the export before deletion. Compare exported IDs with the final list
response. Retry incomplete pages before approving monitor removal.
## Keep webhook delivery evidence
List configured endpoints through [List Webhooks](/api-reference/webhooks/list).
Then call [List Deliveries](/api-reference/webhooks/deliveries) for each relevant
endpoint.
Join each delivery's `streamEventId` to the exported event `id`.
Do not use `x_event_id` as the delivery join key. That value identifies an
external event, not the stored Xquik event row.
Keep `status`, `attempts`, `lastStatusCode`, `lastError`, `createdAt`, and
`deliveredAt`. These fields explain successful deliveries, receiver failures,
and retries still waiting.
Deleting the monitor removes linked delivery attempts. It does not remove the
webhook endpoint. Reuse that endpoint when another monitor emits matching event
types. Test the endpoint before depending on new alerts.
## Handle every delete response
A `202` response starts deletion. Require `success: true`, then poll
`statusUrl`. Close the workflow when that URL returns `404`.
A `400` response means the ID format is invalid. Correct the path value before
another request. Do not substitute an X username for the monitor ID.
A `401` response means authentication failed. Replace the invalid API key or
session. Never expose that credential in logs or support tickets.
Treat a `404` response as an unavailable monitor. It may already be deleted.
It may also belong to another account. Verify the account context before
proceeding.
A `429` response means the rate limit blocked the request. Read
`Retry-After`, wait for that interval, and check the monitor again.
## Resolve an unknown delete result
A client timeout does not prove failure. The server may have completed the
deletion before the connection ended.
Read the same monitor ID after the timeout. A `404` response confirms that the
record is unavailable. A successful read shows that the monitor still exists.
List account monitors as a second check. Confirm that the deleted ID is absent.
Do not rely on an empty event search alone. An event filter can be wrong while
the monitor still exists.
Repeated deletion leaves the final state unchanged. The first accepted request
returns `202`. Later requests return `404` after cleanup finishes.
## Recreate monitoring after deletion
A deleted account monitor cannot resume. Create another monitor when checks must
restart. The replacement receives a different monitor ID.
Use the saved X username, X user ID, and event types for reconstruction. Review
those values before creating the replacement. Do not assume the old filters
still match the current workflow.
Existing webhook endpoints remain available. Confirm their event subscriptions
before connecting the replacement monitor. Run [Test Webhook](/api-reference/webhooks/test)
to validate receiver access and response handling.
Update dependent jobs with the new monitor ID. Replace stored event filters,
verification links, and support references. The deleted ID will continue
returning `404`.
## Account monitor deletion checklist
1. Confirm the monitor ID, X username, and X user ID.
2. Review `eventTypes`, `isActive`, and the deletion reason.
3. Export every required tweet and profile event.
4. Keep required webhook delivery attempts and receiver results.
5. Obtain approval for permanent removal.
6. Send `DELETE` and require `202` with `success: true`.
7. Poll `statusUrl` and require `404 not_found`.
8. List monitors and confirm that the ID is absent.
9. Update references to the removed monitor in other systems.
Pause with `isActive: false` when monitoring may resume. Delete only after the
retention, approval, and verification steps finish.
## Related account monitor operations
Use [List Monitors](/api-reference/monitors/list) to find and verify account
monitors. Use [Get Monitor](/api-reference/monitors/twitter-account-monitor-status)
to confirm the selected ID and its final `404` response.
Use [List Events](/api-reference/events/list) and [Get Event](/api-reference/events/get)
to retain tweet and profile evidence. Use [List Webhooks](/api-reference/webhooks/list)
and [List Deliveries](/api-reference/webhooks/deliveries) for delivery evidence.
Use [Create Monitor](/api-reference/monitors/create) when a replacement account
monitor is required. Store the new ID before restoring dependent workflows.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.