Skip to main content
POST
Twitter bookmark API to save a tweet by ID
10 credits per call · All plans from $0.00012/credit
Each request bookmarks 1 tweet by ID. Each request uses 1 connected X account. Only that account sees its bookmarks. Create a unique Idempotency-Key for the intended bookmark. Store the returned write action and poll statusUrl when needed.

Bookmark one tweet by ID

Put the exact Tweet ID in the request path. Put the connected account username or ID in the body. That account saves the bookmark. Copy Tweet IDs as strings. JavaScript numbers cannot represent every X identifier exactly. This endpoint accepts 1 Tweet ID per request.

Keep bookmarks private to the acting account

X shows a bookmark only to the account that saved it. The post’s author sees a bookmark count, never who saved it. Bookmarking never notifies the author or adds a like. Read the saved posts with Bookmarks.

Save a bookmark receipt

Save the action first. Then update your reading list.

Choose bookmark, like, or read bookmarks

Use Remove bookmark to reverse a bookmark.

Twitter bookmark API questions

Can an API bookmark a tweet by ID?

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

Can other people see the bookmark?

No. X shows bookmarks only to the account that saved them. The author sees the total bookmark count on the post.

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 identifying which connected X account will bookmark the tweet. 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.