Skip to main content
DELETE
Twitter API delete tweet: remove an owned post by ID
10 credits per call · All plans from $0.00012/credit
Use this Twitter API delete tweet route to remove 1 owned post by ID. This delete tweet API accepts 1 Tweet ID per request. Select the connected X account that published the tweet. Save approval evidence before sending the request. Send 1 unique Idempotency-Key for the intended deletion. Store the durable write action and poll statusUrl when needed. Confirm targetId matches the requested Tweet ID after terminal success. X also documents an official Delete Post endpoint. Authenticate with Xquik. Store its durable write response.

Delete one owned tweet by ID

Send the exact Tweet ID in the path. Send its author account in the request body. The connected account must own the target tweet. You cannot delete another account’s tweet with this route. A reply is also a tweet with its own ID. Delete the reply ID without deleting its parent tweet. Use Get Tweet before deletion. Save the returned author, text, creation time, media, and conversation ID. Create a dedicated idempotency key for each intended deletion. Reuse that key only after an interrupted response. Never reuse a create-tweet key for deletion.

Authenticate the tweet owner

Send an Xquik API key or OAuth 2.1 bearer token. Then identify the connected X account with account. The request never accepts an X password or session cookie. Keep API keys on your server, not inside browser or mobile clients. The official X endpoint uses a user access token. Its permissions differ from Xquik authentication. Read X’s Manage Posts guide for that separate contract.

Save tweet deletion evidence

This API workflow cannot restore a deleted tweet. Show the final tweet text during approval. Keep the approver, approval time, and reason beside the Tweet ID. Persist these fields after sending the request:
  • Store id as the durable write action ID.
  • Store request.hash for exact request matching.
  • Store account for the connected tweet owner.
  • Store targetId for the confirmed Tweet ID.
  • Store status, terminal, and statusUrl for polling.
  • Store billing.chargedCredits for the deletion charge.
  • Store safeToRetry before considering another request.
A replacement tweet receives a different Tweet ID. Keep the deleted ID in the audit record. Join replies, analytics, and moderation records with the deleted ID.

Run bulk or scheduled tweet cleanup

This route deletes 1 tweet per request. It does not provide a bulk-delete operation. Feed approved Tweet IDs through the route individually. Create a unique Idempotency-Key for every Tweet ID. Delete tweets in a controlled queue. Store every write action. After HTTP 429, wait for Retry-After before continuing. X publishes separate limits for its Delete Post endpoint. Those limits do not replace Xquik’s response headers. This endpoint does not schedule future deletion. Let your scheduler call it at the approved time. Keep each scheduled Tweet ID and approval reference together.

Verify tweet deletion

A 202 response means the deletion is still active. Poll statusUrl until terminal becomes true. Never submit another deletion while the action remains active. After terminal success, accept targetId, tweetId, or result.id as confirmation. Call Get Tweet with that ID. Store the lookup time and result beside the write action. Save the unavailable lookup beside the successful write action. Before terminal success, an unavailable lookup proves nothing. A missing tweet does not always prove deletion.

Handle delete tweet errors

Never infer failure from a client timeout. Poll the returned action before sending another request. Use Twitter API error handling for every lifecycle field and retry rule.
  • For 400, fix the Tweet ID or account value.
  • For 401, replace invalid Xquik authentication.
  • For 402, add credits before another deletion.
  • For 403, reconnect the selected X account.
  • For 409, keep the original action and payload.
  • For 422, review the rejection before retrying.
  • For 429, wait for Retry-After.
  • For 500 or 503, trust safeToRetry and terminal.

Choose tweet deletion, unlike, or unretweet

Use tweet deletion only when the connected account owns the published post. It removes that post. It does not merely reverse an engagement action. Use Unlike Tweet to remove one account’s like. Use Unretweet to remove one account’s repost. Both actions preserve the source tweet. Never delete the source tweet when a campaign only needs engagement cleanup. Check the route during approval. Record the intended state.

Twitter API delete tweet questions

Can the API delete another user’s tweet?

No. The connected account must own the target tweet. Use the author’s own connected account and exact Tweet ID.

Can the API delete all tweets at once?

No bulk route exists here. Submit 1 approved Tweet ID per request. Preserve each deletion’s key, write action, and terminal result.

Can I schedule a tweet deletion?

Yes, through your own scheduler. Call this endpoint at the approved time. The endpoint itself does not store a future schedule.

Which libraries can delete a tweet?

Any HTTP client can call this REST endpoint. The examples cover cURL, Node.js, Python, and Go. Keep credentials in server-side code.

How should recurring tweet cleanup work?

Select owned Tweet IDs using an approved retention policy. Snapshot each tweet before deletion. Send one deletion, store its action, and verify its terminal result.

Headers

string
Send your Xquik API key in this header. Alternatively, send an OAuth 2.1 bearer token.
string
Send Bearer <token> instead of x-api-key when using OAuth 2.1.
string
required
Unique key for this intended write. Reuse it only for an exact network replay.
string
required
Must be application/json.

Path parameters

string
required
The ID of the tweet to delete. Must be a tweet owned by the specified connected account.

Body

string
required
X username or account ID identifying which connected X account owns the tweet. The @ prefix is automatically stripped if included.

Response

Durable write recovery

Send one unique Idempotency-Key per intended write. Reuse it only for the same account, target, payload, and media.
  1. Store id, the nested hash in request, billing, and statusUrl.
  2. Poll after Retry-After or pollAfterMs when terminal is false.
  3. Trust safeToRetry and nextAction before any new write.

200 Terminal or 202 active

Store terminal results. Poll active actions without creating another write.
  • 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. Preserve the same key.
  • After HTTP 500, retry only when safeToRetry is true.
  • After HTTP 503, poll while terminal is false.
See Get Write Action Status for every lifecycle field, terminal state, billing field, and retry rule.