> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xquik.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Create a Twitter community with the X community API
> Create an X community from one connected account. Submit its name and description, then track its community ID, admin account, and write lifecycle state.
For the complete documentation index, see llms.txt.
## How to create a community on Twitter with Xquik
Call `POST /x/communities` to create a community on Twitter from one connected
account. The request submits a name and optional
description. Xquik then tracks the write until X returns a final result.
Use this route only when the account should own a new community. Use join or
leave routes for an existing community. This route does not add rules, members,
moderators, invitations, posts, analytics, or membership settings.
Each community gives one topic a dedicated space on X.
People can search for communities by name, description, or creator.
They can join a community later. Each member of the community follows
the chosen membership type and community rules. This route
creates the empty community only.
**10 credits per call** ยท [All plans](https://xquik.com/#pricing) from \$0.00012/credit
```bash cURL theme={null}
curl -X POST https://xquik.com/api/v1/x/communities \
-H "x-api-key: xq_YOUR_KEY_HERE" \
-H "Idempotency-Key: community-create-1895432178065391234" \
-H "Content-Type: application/json" \
-d '{
"account": "myxhandle",
"name": "Crypto Traders Hub",
"description": "A community for crypto traders to share insights and strategies."
}' | jq
```
```javascript Node.js theme={null}
const response = await fetch("https://xquik.com/api/v1/x/communities", {
method: "POST",
headers: {
"x-api-key": "xq_YOUR_KEY_HERE",
"Idempotency-Key": "community-create-1895432178065391234",
"Content-Type": "application/json",
},
body: JSON.stringify({
account: "myxhandle",
name: "Crypto Traders Hub",
description: "A community for crypto traders to share insights and strategies.",
}),
});
const data = await response.json();
```
```python Python theme={null}
import requests
response = requests.post(
"https://xquik.com/api/v1/x/communities",
headers={
"x-api-key": "xq_YOUR_KEY_HERE",
"Idempotency-Key": "community-create-1895432178065391234",
},
json={
"account": "myxhandle",
"name": "Crypto Traders Hub",
"description": "A community for crypto traders to share insights and strategies.",
},
)
data = response.json()
```
```go Go theme={null}
package main
import (
"bytes"
"encoding/json"
"fmt"
"net/http"
)
func main() {
body, _ := json.Marshal(map[string]interface{}{
"account": "myxhandle",
"name": "Crypto Traders Hub",
"description": "A community for crypto traders to share insights and strategies.",
})
req, err := http.NewRequest("POST", "https://xquik.com/api/v1/x/communities", bytes.NewReader(body))
if err != nil {
panic(err)
}
req.Header.Set("x-api-key", "xq_YOUR_KEY_HERE")
req.Header.Set("Idempotency-Key", "community-create-1895432178065391234")
req.Header.Set("Content-Type", "application/json")
resp, err := http.DefaultClient.Do(req)
if err != nil {
panic(err)
}
defer resp.Body.Close()
var data map[string]interface{}
if err := json.NewDecoder(resp.Body).Decode(&data); err != nil {
panic(err)
}
fmt.Println(data)
}
```
## Prepare a community creation request
Approve the community name, description, and rules before this call. Keep the
connected owner in the approval record.
Create one idempotency key for the intended community. Reuse it only when the
same request needs network recovery. Use a new key after any approved input
changes.
Community creation workflows should include:
* Checking the final name for spelling and scope.
* Reviewing rules with the future moderation team.
* Recording the owner account and approval reference.
* Saving the returned community and action identifiers.
Do not submit parallel requests with different keys for one intended
community. That can create multiple communities. Read the lifecycle state
before other workflows use the new community.
## Build a reviewable community brief
Create a short brief before calling this endpoint. Record the proposed name,
description, owner account, audience, and moderation purpose. Keep that brief
beside the approval record. Reviewers can then compare the submitted fields
against the approved community identity.
The name is public and hard to change later. Check spelling, capitalization, and
topic scope before approval. Use the description to explain who should join.
Avoid campaign dates or temporary slogans in either field. Those details go out of date
and confuse people who find the community later.
Choose one connected account as the owner. Record its username and
stable account ID when available. Confirm that the account appears in your
connected-account list. Keep the same owner during network recovery. A
different owner means a different write request.
Store these creation inputs together:
* Connected owner username and account ID.
* Final community name and description.
* Approval reference and approving operator.
* Idempotency key for this exact submission.
* Returned action ID and lifecycle state.
Repeat the unchanged
request only after a network timeout. Changed text needs a new approval and key.
## Confirm the community admin account
Choose the connected account before review. X assigns admin ownership to the
original creator. Community admins manage names, descriptions, rules, and
moderators in X. Xquik only sends the creation request.
X requires an eligible admin account. Its official moderator
playbook lists these checks:
* Use a public account.
* Use an account that is at least 6 months old.
* Verify an email address or phone number.
* Keep the account compliant with the X Terms of Service.
X enforces these requirements and can change them. The request has no
eligibility override. It also has no Premium field. Confirm current eligibility
inside X before approval. Save any rejection reason for the operator.
Review the [X Communities moderator playbook](https://help.x.com/en/using-x/communities-moderator-playbook)
before assigning the owner. It explains creator, admin, moderator, and member
responsibilities. Store the chosen account with the approved community brief.
## Plan community rules and membership
Define community rules before creating the community. Rules should describe
the topic, allowed behavior, and moderation response. Do not place temporary
campaign instructions in the public description. Keep the full rule set in
the team's approved moderation record.
X offers open communities and restricted membership. Open
communities show a Join button at the top of the community page. Restricted
communities can let a person request to join. A moderator then accepts or
denies that request. X may also allow member invitations.
This endpoint does not choose a membership type. It does not add community
members or moderators. Configure those settings after creation through the
current X interface. Record the selected mode beside the returned community ID.
Read the [X Communities guide](https://help.x.com/en/using-x/communities) before
opening membership. It covers visibility, roles, invitations, and moderation.
Use the guide as the source for current X behavior. Use this page for Xquik's
API contract.
## Prepare a brand or product community
Use a specific name that explains the shared topic. Write a description that
identifies the intended community members. State who operates the community.
Avoid names that imply an unsupported partnership or endorsement.
Prepare the first discussion topics before launch. Assign community admins and
moderators before invitations begin. Decide who reviews reports and removes
disruptive members. Keep escalation rules outside the public description.
This route cannot publish welcome posts or schedule discussions. It cannot
promote or monetize the community. After launch, publish Community posts with
[Create Tweet](/api-reference/x-write/create-tweet). X may display Community
posts inside a member's Twitter feed.
## Connect the community to a website or app
The request has no website, app, rules, or invitation field. Store those links
in your application after X confirms creation. Associate them with the returned
community ID, owner account, approval, and lifecycle record.
After success, verify the name on the community page. Search
for communities by name, description, or creator through X when available.
X notes that not every community appears in search results. Do not treat search
visibility as proof of creation.
Use the community ID as the stable integration key. Do not key integrations by
the editable display name. Store a verified community URL only after the read
route confirms the new ID.
## Community creation questions
### Do X communities still exist?
Yes. X still publishes current Communities and moderator guidance. This API
creates an X Community through a connected account. X controls feature
availability and account eligibility.
### Do you need X Premium to create a community?
The Xquik request does not accept a Premium setting. X decides whether the
connected account can create the community. Check current X eligibility before
submitting a billable write.
### Can the API add rules, members, or moderators?
No. The request accepts `account`, `name`, and `description`. Set
community rules, membership type, invitations, and moderator roles after
creation. Never send undocumented fields.
### Can the API schedule, grow, or monetize a community?
No. This route creates the community and tracks that write. It does not
schedule posts, invite initial members, run promotions, provide analytics, or
configure monetization.
### How should software handle community creation?
Require an approved brief and one idempotency key. Store the action ID
immediately. Poll the lifecycle, verify the new community ID, and then start
separate membership or publishing workflows.
## Validate the new community
Wait for the write lifecycle to finish before announcing the community. A
`202` response means Xquik accepted the write for processing. It does not prove
that X completed community creation. Follow the returned lifecycle state until
the action reaches its final result.
Capture the new community ID from the confirmed result. Then call
[Community Info](/api-reference/x/community-info). Compare its
name and description with the approved brief. Save the returned community ID
beside the owner account and action ID.
Run these checks before inviting members:
1. Confirm the community ID resolves.
2. Compare the returned name with the approved name.
3. Compare the returned description with the approved description.
4. Confirm the intended owner account remains connected.
5. Record the final write state and verification time.
Repeat the information request after a temporary read failure. Keep the same
key only when every input remains unchanged.
## Handle creation failures
Fix invalid names or missing accounts
before sending another write. Restore credits before retrying a `402` response.
Reconnect the owner after `403`.
A `409` means the key already identifies another request. Compare both request
bodies. Reuse the key only when every creation input matches.
Generate a new key after any approved field changes.
`422 x_account_feature_required` means X won't let this account create communities.
Use another account. Xquik charges nothing.
For other `422` errors, save the rejected request and returned reason. Do not rewrite
the community brief in code. Return it to the operator for review. For
`429`, respect the retry guidance and keep the same approved intent.
After `503`, check the write lifecycle before retrying. A disconnected client
does not prove failure. A retry can create a 2nd community.
| Community creation record | Request or response source | Completion rule |
| - | - | - |
| Owner | Request `account` | Match the connected owner. |
| Name | Request `name` | Keep the approved name. |
| Purpose | Request `description` | Keep the approved description. |
| Replay key | Request header | Reuse it for one exact replay. |
| Action ID | Response `id` | Poll this lifecycle record. |
| State | Response `status` and `terminal` | Stop after a terminal result. |
| Community ID | Response `communityId` | Store it after success. |
| Verification | `GET /x/communities/{id}/info` | Match the name and owner. |
## Headers
Your API key. OAuth bearer authentication is also supported. Generate a key from the [dashboard](https://xquik.com/dashboard).
Unique key for this intended write. Reuse it only for an exact network replay.
Must be `application/json`.
## Body
The connected X account to create the community as. Must be a username you have connected to your Xquik account.
The name for the new community.
Optional description for the community explaining its purpose.
## 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](/api-reference/x-write/get-write-action-status)
for every lifecycle field, terminal state, billing field, and retry rule.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.