Compat: Remove User from Tweet Monitoring API
An x_user_stream-shaped request/response envelope for removing a monitored user, translated onto DELETE /twitter/monitor/{id}. id_for_user is exactly our monitor id -- get it from get_user_to_monitor_tweet, i.e. it is an opaque handle from that list response, which is what our id already is. Cost: Free per call.
POST oapi/x_user_stream/remove_user_to_monitor_tweet removes a monitored user by translating an x_user_stream-shaped request onto DELETE /twitter/monitor/{id}. It takes one required parameter, id_for_user, which is the monitor id returned by GET /oapi/x_user_stream/get_user_to_monitor_tweet. It returns a status field (success or error) and a msg field with a human-readable result. The call costs 0 credits.
Authorization
bearerAuth Pass your API key as a bearer token on every request: Authorization: Bearer <API_KEY>.
In: header
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Response Body
application/json
application/json
application/json
application/json
application/json
application/json
application/json
application/json
curl -X POST "https://example.com/oapi/x_user_stream/remove_user_to_monitor_tweet" \ -H "Content-Type: application/json" \ -d '{ "id_for_user": "b6f2c1a4-9e3d-4c11-8a2f-7d5e6c9b0a11" }'{ "status": "success", "msg": "User removed from tweet monitoring."}{ "error": "bad_request", "message": "Missing or malformed parameter. Fix the request before retrying."}{ "error": "unauthorized", "message": "The API key is missing, malformed, or revoked. Check the Authorization header."}{ "error": "insufficient_credits", "message": "Your balance is exhausted. Top up your credits to continue."}{ "error": "forbidden", "message": "The acting account is not authorized for this write action, or has no logged-in session."}{ "error": "not_found", "message": "The resource does not exist, for example a deleted tweet or a private account."}{ "error": "rate_limited", "message": "Too many requests. Back off and retry with exponential backoff."}{ "error": "server_error", "message": "Something failed on our side. Retry with backoff; if it persists, contact support."}Pricing
| Unit | Price |
|---|---|
| Per call | Free |
When to use
Use this endpoint only if your integration was originally built against x_user_stream's remove-user request/response shape and you want to keep that envelope while removing a monitor. If you are building fresh, call DELETE /twitter/monitor/{id} directly instead of this compatibility wrapper.
Notes
- 404 with an error status if the id_for_user does not exist or belongs to a different API key.
- Irreversible, same as DELETE /twitter/monitor/{id}: there is no undelete.
- Lives at /oapi/x_user_stream/..., not under /twitter/ -- match the base URL in the example exactly.
Related endpoints
- Create Monitor: Watch an X account for new posts and push them to your webhook(s).
- List Monitors: List every monitor on your account.
FAQ
Where do I get the value to pass as id_for_user?
Call GET /oapi/x_user_stream/get_user_to_monitor_tweet first and read the monitor id from its response. id_for_user is exactly our internal monitor id, not the monitored user's Twitter/X user ID, so passing a raw Twitter user ID will not match.
Does removing a monitor here cost credits, and how do I know it worked?
The endpoint costs 0. Check the status field in the response: success means the monitor was deleted, error means it was not, and msg carries the human-readable detail for either outcome.
Compat: Add User to Tweet Monitoring POST
An x_user_stream-shaped request/response envelope, translated onto the exact same underlying monitor system as POST /twitter/monitor -- not a second capability, one system with two request shapes in front of it. Migrating an integration already built against that shape? Point it at this path instead of rewriting it against /twitter/monitor. Free: account administration, not a metered read, billed identically to /twitter/monitor. Cost: Free per call.
Compat: List Tweet-Monitored Users GET
An x_user_stream-shaped response envelope for listing monitored users, backed by the same monitor rows GET /twitter/monitor returns. Honest field mapping, not fabricated: our monitors table stores no numeric Twitter user id and no separate display name, so x_user_id is always null and x_user_name/x_user_screen_name both carry the handle we actually store. is_monitor_profile (profile-change monitoring) is not a capability this API has -- always 0, never reported as on. Cost: Free per call.