Skip to main content
DELETE
Remove Twitter bookmark API to unsave a tweet by ID
10 credits per call · All plans from $0.00012/credit
Each request removes 1 bookmark by Tweet ID. Each request uses 1 connected X account. It never deletes the tweet or changes another account’s bookmarks. Create a unique Idempotency-Key for the intended removal. Store the returned write action and poll statusUrl when needed.

Remove one bookmark by Tweet ID

Put the exact Tweet ID in the request path. Put the connected account username or ID in the body. That account loses the bookmark. This endpoint accepts 1 Tweet ID per request. It never deletes the tweet, likes, or reposts.

Clear many bookmarks

Read the saved posts with Bookmarks. Send 1 request per Tweet ID with its own Idempotency-Key. Keep each removal in your ledger before the next request. Show the account owner the posts before the removal starts. Removed bookmarks don’t come back unless the account saves them again.

Save a removal receipt

Twitter remove bookmark API questions

Can an API remove a bookmark by Tweet ID?

Yes. Send the Tweet ID in the path and the connected account in the body.

How do I remove all bookmarks?

Page through Bookmarks, then remove each post with this route. Each removal costs 10 credits.

Handle errors

Never infer failure from a client timeout. Poll a returned action before sending another request.
  • For 400, correct the Tweet ID or account value.
  • For 401, replace invalid Xquik authentication.
  • For 402, add credits before another request.
  • For 403, reconnect the selected X account.
  • For 409, keep the original action and payload.
  • For 422, review the X rejection before retrying.
  • For 429, wait for Retry-After.
  • For 500 or 503, follow safeToRetry and terminal.

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
Post ID or URL-encoded post URL, such as x.com/nasa/status/20. See path IDs.

Body

string
required
X username or account ID of the connected X account that removes the bookmark. Xquik strips the @ prefix if included.

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 and terminal state. That page also lists every billing field and retry rule.