Skip to main content
DELETE
Twitter DM API: delete a direct message by ID
10 credits per deleted DM · Compare plans

Delete a direct message with the Twitter DM API

This route deletes 1 DM from the connected account’s side of the conversation. The other person still sees it. Xquik charges 10 credits only when X deletes the DM. Put the other person in the path and the DM ID in messageId. DM history and Send DM return DM IDs. Send your connected account in the account query parameter.

Confirm the delete

After the delete, Xquik reads the account’s conversation. A 200 response means the conversation no longer shows the DM. Its result has type: "state_change", the DM id and state: "deleted". A 202 response means Xquik has not confirmed the delete yet. Poll statusUrl until terminal is true. You pay nothing while the delete is pending. Deleting the same DM again also succeeds. For a DM older than the first conversation page, Xquik trusts X’s answer.

Handle delete DM errors

  • 400 invalid_message_id means messageId is not a DM ID. Copy it from DM history.
  • 400 account_required means the account query parameter is missing.
  • 404 account_not_found means the account is not connected to Xquik.
  • 422 x_dm_not_deleted means X still shows the DM. You pay nothing, and safeToRetry is true.
Every other status follows the write rules below. See error handling for each code.

Headers

string
required
Your API key. OAuth bearer authentication is also supported. Generate a key from the dashboard.
string
required
Unique key for this intended delete. Reuse it only for an exact network replay.

Path parameters

string
required
The other person in the conversation: user ID, username with or without @, or URL-encoded profile URL, such as x.com/nasa. See path IDs.
string
required
DM ID from DM history. Anything else returns 400 invalid_message_id.

Query parameters

string
required
X username or account ID of the connected account that sees the DM. Without it, the route returns 400 account_required.

Response

Durable write recovery

Send one unique Idempotency-Key per intended write. Replay the same account, target, payload, and media after a lost response. Keep the original key for that replay.
  1. Store id, the nested hash in request, billing, and statusUrl.
  2. Poll after Retry-After or pollAfterMs when terminal is false.
  3. Retry only when safeToRetry is true.
  4. Use a new key when nextAction.requiresNewIdempotencyKey is true.

200 terminal or 202 active

  • After HTTP 200, store the result and settled billing.
  • After HTTP 202, poll the same action. Never submit another write.
  • After HTTP 400, fix the named field. Use a new idempotency key.
  • After HTTP 401, fix authentication. Do not retry unchanged.
  • After HTTP 402, fund the account before another write.
  • After HTTP 403, reconnect the account.
  • After HTTP 409, keep the original action. Use a new key for new input.
  • After HTTP 422, fix the rejected request before retrying.
  • After HTTP 429, wait for Retry-After. Follow nextAction.
See Get Write Action Status for every lifecycle field, terminal state, billing field, and retry rule.