Compat: Add User to Tweet Monitoring API

POST oapi/x_user_stream/add_user_to_monitor_tweet adds an X username to tweet monitoring using the x_user_stream request/response shape. It takes one required field, x_user_name (without the @), and writes to the same underlying monitor system as POST /twitter/monitor. It returns a status field (success or error) and a msg field describing the result. The call is free.

curl -X POST "https://example.com/oapi/x_user_stream/add_user_to_monitor_tweet" \  -H "Content-Type: application/json" \  -d '{    "x_user_name": "elonmusk"  }'

{  "status": "success",  "msg": "User added to 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

When to use

Use this endpoint when your integration is already built against the x_user_stream request/response envelope and you need to add an X user to tweet monitoring without switching shapes. If you are starting fresh or have no existing x_user_stream integration, use POST /twitter/monitor directly instead, since both write to the same monitor system.

Notes

• Uses the exact same safety checks as POST /twitter/monitor (per-plan slot cap, shared-pool admission, real-account resolution) -- a compat shim never routes around a check the native endpoint enforces.
• 403 with a plan-upgrade message if you are already at your monitored-account cap. 503 if the shared pool cannot currently serve one more monitor at the published interval. 400 if x_user_name does not resolve to a real X account.
• Lives at /oapi/x_user_stream/..., not under /twitter/ -- match the base URL in the example exactly.
• Native-first: prefer POST /twitter/monitor for new integrations. This path exists for migration, not as the primary way to create a monitor.

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

Does this create a separate monitor from POST /twitter/monitor?

No. It writes to the exact same underlying monitor system, just through an x_user_stream-shaped request and response envelope instead of the native Create Monitor shape. Use whichever shape matches the client integration you already have; the monitored result is identical either way.

What happens if x_user_name is invalid or already being monitored?

The response status field returns error and the msg field carries a human-readable explanation. Since params only accept a single x_user_name string with no additional flags, there is no way to pass retry or dedup options in the request itself; handle those cases by inspecting status and msg after the call.