X write
Twitter like API: like a tweet by ID with status
Use the Twitter Like API to like one tweet by ID. Store the connected account, durable action, terminal result, billed credits, and safe retry decision.
- 200
- 202
- 400
- 401
- 402
- 403
- 409
- 422
- 429
- 500
- 503
POST
Twitter like API: like a tweet by ID with status
10 credits per call · All plans from $0.00012/credit
Idempotency-Key for the intended like.
Store the durable write action and poll statusUrl when needed.
Confirm the returned target matches the requested Tweet ID.
X documents its separate Like Post endpoint.
X says not to auto-like or bulk-like Tweets in its Developer Guidelines.
Keep every like user-initiated.
Like 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 performs the like. Copy Tweet IDs as strings. JavaScript numbers cannot safely represent every X identifier. Keep the selected Tweet ID beside the approving user. This endpoint accepts 1 Tweet ID per request. It does not fetch Tweets, create reposts, or publish replies. Use Get Tweet before showing an approval screen.Keep every like user-initiated
Require a clear user choice before each like. Show the tweet text, author, and Tweet ID during approval. Store who approved the like and when. Do not build auto-like, bulk-like, or purchased-like workflows. Do not select scraped tweets and like them without user approval. Only send the like that your user picked. A review queue can prepare candidates without performing actions. Your user must choose the exact tweet before this endpoint runs. Keep the approval reference in the action ledger.Authenticate the connected X account
Send an Xquik API key or OAuth 2.1 bearer token. Then identify the connected X account withaccount.
The request never accepts an X password or session cookie.
Keep Xquik credentials in server-side code.
Do not expose them in mobile apps or browser bundles.
Reconnect that X account when you receive account_needs_reauth.
The official X endpoint uses a user access token.
Its authentication differs from the Xquik contract.
Read X’s Like Post guide for that endpoint.
Save a durable like receipt
Never treat a transport response as sufficient proof. Save the action first. Then update your like record. Keep the request and response identities together.
Persist these response fields:
- Store
idas the durable write action ID. - Store
request.hashfor exact request matching. - Store
accountfor the connected X account. - Store
targetIdorresult.idfor the liked Tweet ID. - Store
status,terminal, andstatusUrlfor polling. - Store
billing.chargedCreditsfor the settled charge. - Store
safeToRetrybefore considering another request.
Poll pending likes and verify completion
A200 response contains a terminal action.
A 202 response means the like remains active.
Poll statusUrl until terminal becomes true.
Do not submit another like while the first action remains active.
After success, confirm the result matches the requested Tweet ID.
Preserve an already-liked terminal result as successful convergence.
Use User Likes only when current read proof matters.
Store the read time separately from the action time.
Read visibility can limit independent verification.
Prevent duplicate tweet likes
Create 1 idempotency key for the intended account and Tweet ID. Reuse that key only after an interrupted response. Never reuse it for a different account or tweet. An HTTP409 means the key already protects another payload.
Keep the original action and inspect its request hash.
Create a new key only for a new user-approved intent.
Idempotency prevents duplicate submissions inside the Xquik workflow.
Still check approval, terminal status, and the acting account.
Handle Twitter like API errors
Never infer failure from a client timeout. Poll a returned action before sending another request. FollowsafeToRetry for ambiguous write outcomes.
- For
400, correct the Tweet ID or account value. - For
401, replace invalid Xquik authentication. - For
402, add credits before another like. - 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 forRetry-After. - For
500or503, followsafeToRetryandterminal.
Choose like, unlike, or read likes
Use this route only to add a like from one connected account. Use Unlike Tweet to reverse that account’s like. Use read endpoints when no engagement action is needed.
Liking does not create a repost, reply, bookmark, or follow.
Choose each action explicitly during approval.
Twitter like API questions
Can an API like a tweet by ID?
Yes. Send the Tweet ID in this route’s path. Send the connected acting account in the JSON body. Keep the like user-initiated.Does this endpoint bulk-like tweets?
No. It accepts 1 Tweet ID per request. X prohibits bulk-like and auto-like behavior. Do not loop through candidates without individual user approval.How does Twitter like API authentication work?
Authenticate to Xquik with an API key or OAuth 2.1 bearer token. Select a previously connected X account withaccount.
Never send an X password.
How should a Twitter API like tweet retry work?
Store the durable action first. Poll whileterminal is false.
Retry only when safeToRetry is true.
Can the same API like, repost, and reply?
Xquik documents separate routes for each action. Use Retweet for a repost. Use Create Tweet for a reply.Which libraries can like 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.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 like.
Body
string
required
X username or account ID identifying which connected X account will like the tweet. The
@ prefix is automatically stripped if included.Response
Durable write recovery
- Store
id, the nestedhashinrequest,billing, andstatusUrl. - Poll after
Retry-AfterorpollAfterMswhenterminalisfalse. - Trust
safeToRetryandnextActionbefore 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 forRetry-After. Preserve the same key. - After HTTP
500, retry only whensafeToRetryistrue. - After HTTP
503, poll whileterminalisfalse.
- 200
- 202
- 400
- 401
- 402
- 403
- 409
- 422
- 429
- 500
- 503
Twitter like API: like a tweet by ID with status