Skip to main content
DELETE
Twitter Unfollow API: Unfollow One X User by ID

Unfollow One Twitter User by ID

Use this Twitter unfollow API endpoint for 1 target user ID. Each Twitter API unfollow request names 1 connected X account. Verify the target user ID and acting account before approval. Compare X’s separate Unfollow User endpoint.
10 credits per call · All plans from $0.00012/credit
Action-specific rate limit: Unfollow shares the follow-action limits: 20 requests per minute and 400 per day. The DELETE tier also applies. A breached limit returns 429 Too Many Requests.

Authenticate and Select the Relationship

Send an Xquik API key or OAuth 2.1 bearer token. Never send an X password or session cookie. The path ID names the profile that the acting account follows. The body names the connected account that will stop following it. Use the stable numeric user ID as the relationship key. Keep the username and profile name as review labels. Show both profiles before a user approves the write action. The profile page and unfollow button are manual X controls. This endpoint supports an approved Twitter management workflow.

Unfollow Twitter Accounts Safely

Create a new idempotency key whenever the relationship changes. Never reuse the key from an earlier follow action. Reuse the unfollow key only after an interrupted network request. Store the returned action ID, request hash, and statusUrl immediately. Poll the same action while terminal remains false. Never submit a second write just because the first action is active. The endpoint accepts 1 target user ID per request. It exposes no mass unfollow body or bulk unfollow feature. Queue approved targets separately when you unfollow Twitter accounts in bulk. Each row needs its own target, reason, approval, and idempotency key. Separate rows isolate failures across multiple Twitter accounts. A failed row must not erase successful unfollow actions. Batch queues save time while preserving individual approvals. Review unfollowing accounts before sending any write. A social media team can stage approved rows for later processing. For accounts on Twitter, store each acting account and target ID separately. Respect X’s terms of service and every returned rate limit. Unfollow people only after a clear user or workflow decision.

Select Inactive Users Before Unfollowing

This write endpoint does not discover inactive users or non-followers. Read Following before selecting cleanup targets. Define inactivity from an approved timestamp or business rule. Never infer inactivity from a missing profile or stale export. Store the selection rule with the target user ID. Review the acting account and target as separate fields. Then send 1 approved unfollow action for each relationship.

Verify the Twitter Unfollow API Result

Poll statusUrl until the durable action becomes terminal. Store the final status, billing fields, and request identifiers. Use Check Follower when current proof matters. Check Following to confirm the target disappeared from the outbound list. No response field says whether X sent a notification. Do not claim whether X notified the target account. Verify the relationship instead of inferring client behavior.

Choose Unfollow or Remove Follower

Unfollow stops the connected account from following the target profile. Remove Follower ends one inbound relationship. Use Remove Follower when someone should stop following the connected account. Unretweet removes one repost but preserves every follow relationship. Delete Tweet removes one post but preserves follower relationships. Don’t mix these write actions in one management tool flow.

Handle Twitter API Unfollow Errors

Fix the target user ID or acting account after 400. Replace Xquik authentication after 401; reconnect after 403. Add credits after 402; review rejected input after 422. Keep the original action after an idempotency conflict at 409. Honor Retry-After after 429. After 500 or 503, check safeToRetry before retrying.

Twitter Unfollow API Questions

How Do I Unfollow Someone on Twitter with an API?

Approve the target user ID and connected account. Send this DELETE request, then poll the returned action until terminal.

Can I Mass Unfollow or Schedule Unfollow Actions?

Use your scheduler to queue 1 approved target per request. Throttle the queue to both documented limits above.

Can I Unfollow Someone Without Them Knowing?

Xquik cannot confirm whether X sends a notification. Confirm only the outbound relationship change.

Do I Need Unfollow Tools or Browser Extensions?

No. Use any HTTP client or the cURL, Node.js, Python, and Go examples. A third-party service still needs an approved connected account. Some HTTP clients offer free plans, but Xquik credits still apply.

How Do I Manage Several Connected Accounts?

Repeat approval for each acting account. Never reuse one action ID across accounts.

How Do I Get an API Key?

Create an Xquik API key in the dashboard. You can also send an OAuth 2.1 bearer token.

Headers

string
Send your Xquik API key. Generate one from the dashboard.
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 X user ID of the account to unfollow.

Body

string
required
X username or account ID of your connected account to act as.

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.