object
Communities
X community details API for members & rules
Retrieve an X community’s name, description, member count, creator, moderators, rules, join policy, banner, and creation time. Includes request fields.
- 200
- 400
- 401
- 402
- 404
- 424
- 429
- 502
GET
X community details API for members & rules
Use the X communities API to resolve one community. Then read its members, moderators, rules, or tweets. Keep its numeric ID for later requests.
Use member routes for profile rows. Use tweet routes for posts and engagement counts. Use extraction jobs to save CSV, JSON, or XLSX output.
Use
The community ID is empty or invalid.
Missing or invalid API key.
The community could not be resolved. Check the community ID.
The read service returned an error. Retry after a short delay.
Your tier rate limit was exceeded. Wait for the
Opted-in normalized v1 calls return 424 when the read service fails.
Validate an X community before extraction
Check community details for every numeric community ID. Confirm the community name, description, creator, join policy, rules, and banner before requesting members or tweets. This prevents exports from using the wrong X community. Keep the returned community ID as a string. Store the creator and moderator details separately from the member count. Membership totals can change while the community identity remains stable. Use the rules and join policy to give analysts the correct context. They describe how the Twitter community operates. They do not replace member rows, moderator profiles, or community tweets. After validation, choose the smallest matching route. Fetch member profiles for audience review. Fetch moderators for governance review. Fetch recent tweets to review posts and engagement. Use saved extraction jobs to produce CSV, JSON, or XLSX output.Choose the right Twitter community API
Start with community details when the numeric ID needs validation. Then choose the route that matches the records you need.Community details
Get the name, description, creator, rules, policies, and banner. Keep member and moderator counts with the record.
Community members
Retrieve member profiles with usernames, bios, verification, follower counts, and cursor pagination.
Community tweets
Retrieve recent tweets, authors, replies, reposts, likes, quotes, media, and cursor pages.
Keyword search
Search one community for matching tweets. Keep the query and cursor with each page.
Moderator profiles
Retrieve the smaller moderator roster without treating every member as a moderator.
Saved exports
Run a community extraction to save CSV, JSON, or XLSX output.
Choose community metadata
Use this route for community metadata, rules, policies, and counts. It returns one community record, not member profiles or tweet rows. Use member and tweet routes for those collections.GET /x/communities/{id}/info when a workflow needs one durable community
profile row before member exports, moderator review, content routing, or CRM
enrichment. Store community_id, community_name, description,
member_count, moderator_count, policy fields, creator,
banner_url, created_at, primary_topic_name, and rule_count.
Qualify a community before collecting profiles or tweets
Read community metadata before starting a member or tweet export. This check prevents a copied community ID from sending results into the wrong project. Confirmcommunity.id and community.name first. Save both values with the
planned member or tweet export. Names can change, while the numeric ID anchors
later member and tweet pages.
Review description and primary_topic for research relevance. Keep this
classification separate from tweet text. Community metadata describes the
space, while tweet routes return individual posts.
Check join_policy and invites_policy before planning member collection.
Do not infer either policy from member counts. Store the returned values
exactly, including missing values.
Use member_count to estimate roster size. Use moderator_count only for
staffing context. Neither count replaces the paginated member or moderator
routes.
Review is_nsfw before sharing banners, descriptions, or tweets. Follow the
receiving system’s content rules. Keep API responses unchanged.
Capture every community rule with its ID, name, and description. Preserve the
returned order. Do not merge several rules into one undocumented summary.
Finish the qualification record with these decisions:
- Continue to member profiles, moderator profiles, tweets, or keyword search.
- Stop because the community ID or subject is incorrect.
- Require a reviewer before handling sensitive community content.
- Refresh metadata later because a required field is unavailable.
Create a community qualification manifest
Create one manifest before starting member, moderator, or tweet collection. Use the returned community ID as its stable key. Record these community facts:- Record the community name and description.
- Record member and moderator counts.
- Record join and invitation policies.
- Record primary topic and content-sensitivity state.
- Record the creator profile and banner URL when returned.
- Record every rule ID, name, and description.
Use community metadata to choose the next route
The member route returns paginated profile rows. See Community Members. The member count only estimates the expected roster size. Use Community Moderators for moderator profiles. The moderator count does not expose those usernames or user IDs. Use Community Tweets for the unfiltered community timeline. Preserve community ID and cursor with every page. Use Community Search for matching tweets. Preserve the exact keyword expression and sort mode with every result. Keep the creator object for ownership context. Require route evidence before exporting that profile as a member or moderator.Detect community metadata drift
Compare manifests by stable community ID. Never join them by community name. Report name, description, topic, policy, rule, and sensitivity changes separately. A member-count change does not prove a policy change. Track community rules and tweets independently. Store both retrieval times and both returned values. Preserve absent fields. Never invent policy or count defaults. Refresh this endpoint before long-running exports. Attach the newest manifest ID to every new collection job. Keep earlier manifests immutable for audits.Path parameters
string
required
Community ID (numeric string).
Headers
string
Full account key. Sessions and OAuth also work.
string
Bearer xq_your_guest_key_here authenticates paid_reads guest keys. Direct MPP uses the Payment ... credential. Get it from the WWW-Authenticate: Payment challenge.Response
200 OK
object
Community details.
Community object fields.
string
Community ID.
string
Community name. Omitted if unavailable.
string
Community description. Omitted if empty.
number
Total member count. Omitted if unavailable.
number
Total moderators. Omitted if unavailable.
string
Join policy (e.g.
Open). Omitted if unavailable.string
Invitation policy. Omitted if unavailable.
boolean
Whether the community is marked sensitive. Omitted if unavailable.
object
Creator profile with
id, username, verified, and optional name. Omitted if unavailable.string
Banner image URL. Omitted if unavailable.
string
ISO 8601 creation timestamp. Omitted if unavailable.
Primary topic with
id and name fields. Omitted if unavailable.object[]
Community rules, each with
id, name, and description. Omitted if unavailable.400 Invalid community ID
401 Unauthenticated
402 Payment required
Account keys get account options; guest keys get guest top-up only. Anonymous calls get a direct MPPWWW-Authenticate: Payment challenge.
They also get a guest wallet creation action.
No checkout starts automatically. Confirm any payment action.
404 Community not found
502 X API unavailable
429 Rate limit exceeded
Retry-After header before retrying.
424 Dependency failed
Next steps. Community Members to list members, or Community Tweets to browse posts.
- 200
- 400
- 401
- 402
- 404
- 424
- 429
- 502
X community details API for members & rules