X Communities API: How Do You Read Community Posts and Post to a Community?

We read the X API v2 reference and its OpenAPI file (docs.x.com/openapi.json) for anything that touches communities. Community Notes are a separate product and are left out. This is the complete list:

What is missing matters more than what is there. The v2 reference has no endpoint that returns a community's posts, its members or its moderators, and the search operators reference lists no community operator. So with the official API you can describe a community and post into it, but you cannot read its feed or its member list. That is the gap this page fills.

Two details from the docs are worth knowing before you code. First, the Communities Search introduction shows an app-only Bearer token in its example, while the OpenAPI file lists only user-context auth for that endpoint, so test with a user token if app-only fails. Second, the share_with_followers field description in the API reference talks about super-follower posts, while the July 2025 changelog entry says it broadcasts a community post to your followers' timelines, matching the "Also share with followers" checkbox on x.com. The changelog is the more specific source.

The same tasks, side by side. Official prices are from X's pricing page (pay-per-usage); TwitterAPI.io prices are from our pricing page and each endpoint's reference page.

For metadata the ratio is $0.005 / $0.0002 = 25x per community. For a post the ratio is $0.015 / $0.002 = 7.5x per post, before the one-time $0.10 login. For a community's posts, members and moderators there is no official price to compare, because there is no official endpoint.

Every community endpoint takes a numeric community_id. The easiest place to get it is the community's own URL: open the community on x.com and copy the number from x.com/i/communities/1493446837214187523. That ID belongs to Build in Public, the community used in every example below.

If you only have a topic, the official GET /2/communities/search?query= endpoint returns matching communities with their IDs. TwitterAPI.io's get_tweets_from_all_community searches posts, not communities, and in our test its posts did not carry a community ID (communityInfo was null on every post), so use it to watch topics, not to discover IDs.

GET /twitter/community/info takes one parameter, community_id, and costs 20 credits per call. Its reference page notes that it is slower than most endpoints; ours answered in 1.4 seconds. The response below is real, trimmed where marked: rules and profiles are shortened, nothing else is changed.

Compared with the official lookup, the extra fields are the useful ones for moderation and research tools: rules (each with a name and description), question (the prompt new members answer), moderator_count, invites_policy, primary_topic, creator, admin as full profiles, and members_preview. role is the calling account's role, so for an API-key read it is always NonMember.

GET /twitter/community/tweets returns the community's posts newest first, 20 per page. Pass next_cursor back as cursor to get the next page, and stop when has_next_page is false. Each post has the same tweet object as our search and timeline endpoints, with the full author profile embedded, so one call gives you text, counts, media, links and who posted.

A full page of 20 posts costs 20 × 15 = 300 credits, $0.003. The three pages in our test, 60 posts, cost 900 credits, $0.009. Before your first payment the rate limit is 0.2 requests per second, which is why the script waits between pages; once you have paid it is 20 requests per second.

The sample post below is a real response with the post ID, URL, text, handle and date redacted, because community posts are mostly written by private individuals. Everything else is as returned. The post object does not repeat the community_id; you already know it from the request.

GET /twitter/community/members and GET /twitter/community/moderators each take community_id and an optional cursor, and return 20 full user profiles per page (snake_case fields such as screen_name, followers_count, statuses_count, created_at, can_dm). For Build in Public the moderators call returned all 6 moderators in one page (has_next_page: false), matching moderator_count in the metadata. The members call returned 20 profiles with has_next_page: true; with 269,012 members, a full export would take roughly 13,451 pages, so plan members reads as a sample or a slow background job, not a single request.

Moderators of this community are public project and founder accounts listed on its page, so the response below is shown with their real handles. Member profiles are not shown, for the same privacy reason as the posts.

GET /twitter/community/get_tweets_from_all_community takes query (keywords only, per its reference page) and queryType (Latest or Top), and returns posts from any community that match. It is the endpoint for monitoring a topic inside communities when you do not know which communities discuss it. Our python query with Top returned a full first page with has_next_page: true.

Use it for discovery and topic tracking; once you know which community matters, switch to /twitter/community/tweets for that community's complete feed in order.

To give the endpoints a realistic shape, we read the 60 newest posts of Build in Public (269,012 members, primary topic Entrepreneurship, open join policy) in three pages, collected in 2026. The question: how fast does a large community move, and what do its posts look like when you read them through the API?

What it means for a build: at about 45 posts an hour, polling this community every 15 to 20 minutes catches every new post in one page, and a full page costs $0.003. A community this size produces about 1,080 posts a day if the pace holds, which is about $0.16 a day to read every post at 15 credits each. The 40% media share is high because the community's own rules ask members to share screenshots and screencasts. Engagement is low at read time because most posts were minutes old; if you study engagement, re-read posts by ID a day later.

The official way. Call POST /2/tweets with your text and community_id, signed with a user-context token (OAuth 2.0 with the tweet.write scope, or OAuth 1.0a user context). The reference defines community_id as "Community to post the tweet to", a numeric string. Add share_with_followers: true to also put the post on your followers' timelines. X's data dictionary notes that only members of a community can engage and participate in it, so the account must have joined the community first. On the pay-per-usage rate card each post is Post: Create, $0.015 per request.

TwitterAPI.io posts as your own X account through a logged-in session. POST /twitter/user_login_v2 takes user_name, email, password, the optional but recommended totp_secret and a required proxy, and returns login_cookies for $0.10. POST /twitter/create_tweet_v2 then takes login_cookies, tweet_text, proxy and the optional community_id, and returns tweet_id; it costs $0.002 per HTTP 200 call, whether or not X ends up showing the post. If the account is not yet a member, POST /twitter/join_community_v2 with the same cookies and community_id joins it ($0.002).

Read before you automate. Every write acts as that account, and X can rate-limit, lock or suspend it. Communities have their own rules on top of X's: Build in Public, for example, lists "No self-promotion", "No engagement farming" and "Use a personal account". Keep a human pace, have a person write or approve each post, and never post the same text into several communities. Sessions can expire; when a post comes back with a non-success status, log in again once and stop if it fails again.

Pricing side by side for one post: $0.015 on X's Post: Create line versus $0.002 per call here, 7.5x, plus the $0.10 login, which is reused until the session expires.

TwitterAPI.io is pay-as-you-go: 100,000 credits = $1, purchased credits never expire, and you pay for the data returned. New accounts that pass the automatic bot check get up to $1 of free credits (at most 100,000 credits, no card, one per person or network, expiring after 31 days). Full rates and subscription plans are on the pricing page.

Question: what do the community read endpoints return for one large public community, and how does that community's feed look over a short window?

Calls: 8 read calls in one run in 2026, at most one per second: community/info, three pages of community/tweets, one page each of community/members and community/moderators, one get_tweets_from_all_community query (python, Top) to check the response shape, and one keyword search to look for community links. No write endpoint was called.

Sample: 60 posts from 58 authors in Build in Public, 20 members, 6 moderators. Raw responses are not published; we keep only per-post numbers (no IDs, text or handles) and the community's public metadata.

What it cannot show: one community over 80 minutes is not all communities or a full day. Activity varies by hour and topic, and engagement counts were read minutes after posting.

Official API facts come from the X API v2 reference, its OpenAPI file, the data dictionary, the changelog and the pricing page, all read in 2026.