Skip to main content
DELETE
How to delete a community on Twitter via API

How to delete a Twitter community through REST

Call DELETE /x/communities/{id} for one community owned by a connected account. Send its exact community_name to confirm the target. This route removes the community, not the connected X account. Use Leave Community to remove one account’s membership. Use Delete Tweet to remove one owned Community post.
10 credits per call · All plans from $0.00012/credit

Archive records before you delete a Twitter community

Confirm the community ID, owner, exact name, reason, and approver. Create one Idempotency-Key for that deletion. Reuse it only during unchanged network recovery. Xquik has no restore route. Plan for permanent removal. Archive required records before approval:
  • Save the name, description, rules, creator, and policies from Community Info.
  • Follow every Community Tweets cursor. Store tweet IDs, authors, text, timestamps, media URLs, replies, reposts, and likes.
  • Follow every Community Members cursor. Store stable user IDs and the final hasMore value.
  • Export Community Moderators separately. Member rows do not prove moderator roles.
X says Community posts remain after you delete their Community. Review the X Communities guide before removal. Keep your archive even when those posts remain visible elsewhere.

Verify permanent community deletion

Store the action ID after 200 or 202. Poll while terminal is false. After terminal success, call Community Info. An unavailable community confirms removal. A temporary read failure does not. Repeat the read before starting another deletion.

Fix Twitter community deletion errors

Fix invalid fields after 400. Replace credentials after 401. Add credits after 402. Reconnect the owner after 403. Verify the account and community after 404. Resolve key conflicts after 409. Review rejected requests after 422. Honor Retry-After after 429. Check safeToRetry after 500 or 503.

Delete Twitter community questions

Can you delete a Twitter community?

Yes. Send the community ID and exact name through the connected owner. Xquik then returns a tracked write action.

Does deletion affect the owner’s X profile?

No profile field appears in the request body. The route targets one community ID. It does not disconnect or delete the owner’s X account.

Can a deleted community be restored?

Xquik documents no restore endpoint. Archive first and treat deletion as permanent within this API workflow.

Can I transfer ownership instead?

This route has no ownership-transfer field. Complete any supported transfer in X before deletion, then verify the intended owner.

What happens to members and community posts?

Members lose access to the deleted Community. X says it keeps existing Community posts when you delete the Community. Archive required posts before removal. Use Delete Tweet for an owned post.

Headers

string
required
Your API key. OAuth bearer authentication is also supported. Generate a key from the dashboard.
string
required
Unique key for this intended write. Reuse it only when every field remains unchanged after interruption.
string
required
Must be application/json.

Path parameters

string
required
The ID of the community to delete.

Body

string
required
The connected X account that owns the community. Must be a username you have connected to your Xquik account.
string
required
The exact community name. Send it to avoid deleting a different Community.

Response

Connect the requested account, then submit a newly approved write.

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, terminal state, billing field, and retry rule.