Skip to main content

Overview

Communities are parent groups that contain linked subgroups. They use the w:g2 IQ namespace for mutations and MEX (GraphQL) for metadata queries. This guide covers creating communities, linking and unlinking subgroups, querying subgroup metadata, identifying group types, sending encrypted reactions to Community Announcement Groups, and posting channel comments.

Accessing the Community API

All community operations are accessed through the community() method:
See Community API reference for the full API.

Creating a community

By default, create_general_chat is true, so a general chat subgroup is created alongside the community. See Community API reference for details.

Community creation options

Customize the community with CreateCommunityOptions:
If a description is provided, it is set via a follow-up IQ after creation — the group create stanza does not support inline descriptions for communities.

Deactivating a community

Deactivate (delete) a community. Subgroups are unlinked but not deleted:
See Community API reference for details.

Managing subgroups

Link existing groups as subgroups of a community:
See Community API reference for details.

Create a new subgroup

Create a brand new group that’s already linked as a subgroup of a community, in a single call:
This is a shortcut for creating a group and then calling link_subgroups — both steps happen in a single round-trip instead of two. See Community API reference for details.

Hidden subgroups

Every subgroup has a visibility fixed at creation or link time. SubgroupVisibility::Visible (the default) lists the subgroup in the community’s subgroup list for everyone. SubgroupVisibility::Hidden omits it for users who are not members, so only members and admins see it. Visibility is set once. WhatsApp does not support changing a subgroup’s visibility later; to swap a linked group between visible and hidden you must unlink and re-link it. Create a subgroup as hidden with create_subgroup_with_options:
Link a mix of visible and hidden groups in a single request with link_subgroups_with_options:
get_subgroups reports each subgroup’s current visibility on CommunitySubgroup::is_hidden_group. Unlink subgroups from a community:
When remove_orphan_members is true, members who are only in the community through the unlinked subgroups are removed from the community. See Community API reference for details.

Remove participants from a community

Remove participants directly from a community (as opposed to from a single subgroup):
See Community API reference for details.

Join a subgroup

Join a linked subgroup via the parent community:
See Community API reference for details.

Querying community information

List communities you’re in

Fetch all parent/community groups the logged-in account currently participates in. Use list_participating for the slim overview shape (id, subject, hierarchy, participant count) or fetch_participating_metadata when you need the full state:
See Community API reference for details.

List subgroups

Fetch all subgroups of a community via MEX (GraphQL):
See Community API reference for details.

Get subgroup participant counts

Fetch participant counts per subgroup without fetching full subgroup details:
See Community API reference for details.

Query linked group metadata

Query a specific linked subgroup’s metadata from the parent community:
See Community API reference for details.

Get all participants across subgroups

Fetch all participants across all linked groups of a community:
See Community API reference for details.

Identifying group types

Use the group_type function to classify a group within the community hierarchy:
The classification is based on these GroupMetadata fields: See Groups API reference for all GroupMetadata fields. Prefer the GroupHierarchy enum on GroupOverview when you only need the hierarchy classification — group_type(&metadata) is a projection of the same information.

Community Announcement Group (CAG) reactions

The default announcement subgroup of a community — the one where is_default_sub_group is true — is a Community Announcement Group (CAG). CAGs require encrypted reactions; plaintext reactions are silently dropped by the server. client.send_reaction() handles this transparently. The same call works for DMs, regular groups, and CAGs with no change to your code:
For CAG chats the library checks the internal is_community_announce flag on its send-path routing snapshot (populated from metadata and cached). When true, the reaction is encrypted with the target post’s messageSecret (captured when the post was received) and shipped as an enc_reaction_message envelope. If the parent secret is not available the call fails with a descriptive error rather than emitting a plaintext reaction the channel would drop. Incoming encrypted reactions from CAG posts are decrypted transparently by the receive path and surfaced as a normal reaction_message event. The key field is filled from the envelope’s target_message_key, so your event handler looks identical to a regular group reaction:

Channel comments

Post encrypted threaded replies under a CAG post using client.comments():
For arbitrary message bodies, use send_message:
Comments require the parent post’s messageSecret to have been captured when the post was received (via msg_secret_policy). If it was not captured the call returns an error explaining that the secret is missing. Each comment carries a fresh messageSecret of its own so it can receive encrypted reactions. The comment’s secret is persisted under the comment’s own id and sender.

Receiving comments

The client decrypts incoming encrypted comments transparently on the receive path. You receive the decrypted body as part of a normal Event::Messages batch. The inner Message proto has no slot for the parent post key, so you read the threading link off InboundMessage::comment_target instead:
comment_target is None for all other message types.

Error handling

Community mutations return anyhow::Error, while MEX-based queries (get_subgroups, get_subgroup_participant_counts) return MexError:

Next steps