Skip to main content

Overview

This guide covers group operations including creation, participant management, and metadata updates using the whatsapp-rust library.

Accessing the groups API

All group operations are accessed through the groups() method:
See Groups API reference for the full API.

Creating groups

Basic group creation

See Groups API reference for full details.

Group creation options

You can also use the builder pattern:
See Groups API reference for all options.

Group constraints

GroupCreateOptions.subject is a plain String. Validated types GroupSubject and GroupDescription are used by set_subject and set_description respectively.

Querying group information

Get group metadata

See Groups API reference for metadata fields.

List all groups

See Groups API reference for details.

Query group info (internal)

For lower-level access with caching:
See Groups API reference for details.

Updating group metadata

Change group subject

See Groups API reference for details.

Set or delete group description

See Groups API reference for details.
The prev parameter can be used for conflict detection. If provided and the current description ID doesn’t match, the operation may fail. Pass None if you don’t need this check.

Managing participants

Add participants

See Groups API reference for response codes.

Remove participants

See Groups API reference for details.

Promote to admin

See Groups API reference for details.

Demote admin

See Groups API reference for details.

Leave group

See Groups API reference for details.
See Groups API reference for details.
Resetting the invite link (reset = true) invalidates the old link. Anyone with the old link will no longer be able to join.

Join a group via invite

You can join a group using an invite code or a full https://chat.whatsapp.com/... URL. The method automatically strips the URL prefix if present.
If the group has membership approval enabled, the result will be PendingApproval instead of Joined. See Groups API reference for details.

Accept a V4 invite message

V4 invites are sent directly by a group admin as a GroupInviteMessage, rather than shared as a URL. Use join_with_invite_v4 to accept these invites:
V4 invites have an expiration timestamp. The method automatically checks whether the invite has expired and returns an error if it has. Pass 0 as the expiration to skip the check.
See Groups API reference for details.

Preview a group before joining

Use get_invite_info to fetch group metadata from an invite code without joining:
See Groups API reference for details.

Membership requests

When a group has membership approval enabled, new members must be approved by an admin. You can view, approve, and reject pending requests.

Get pending requests

See Groups API reference for details.

Approve or reject requests

See Groups API reference for details.
You must be a group admin to view, approve, or reject membership requests.

Cancel membership requests

Users can cancel their own pending membership requests:
See Groups API reference for details.

Revoke invitation codes

Admins can revoke invitation codes from specific participants:
See Groups API reference for details.

Batch operations

Batch query group info

Query metadata for multiple groups in a single request (up to 10,000 groups):
See Groups API reference for details.

Batch fetch profile pictures

Fetch profile pictures for multiple groups at once (up to 1,000 groups):
See Groups API reference for details.

Set or remove the group picture

Admins can update the group’s profile picture by uploading JPEG bytes, or remove it with a dedicated call:
See Groups API reference for details.

Group settings

Member add mode

Control who can add new members:
See Groups API reference for details.

Membership approval mode

Require admin approval for new members:
See Groups API reference for details.

Announcement mode

Toggle announcement mode on an existing group (only admins can send messages):
See Groups API reference for details.

Frequently-forwarded messages

Restrict or allow frequently-forwarded messages in the group:
See Groups API reference for details.

Admin reports

Enable or disable admin reports in the group:
See Groups API reference for details.

Group history sharing

Enable or disable sharing group history with new members:
See Groups API reference for details. Control who can share invite links. This setting is updated via the MEX protocol:
See Groups API reference for details.

Message history sharing mode

Control who can share message history with new members. This setting is updated via the MEX protocol:
See Groups API reference for details.

Limit sharing

Enable or disable limit sharing in the group. This setting is updated via the MEX protocol:
See Groups API reference for details.

Privacy tokens on group operations

When server-side A/B experiment flags are enabled, the library automatically attaches privacy tokens (tc_token) to participants during group creation and participant addition. This matches WhatsApp Web’s behavior and requires no changes to your code. The following AB prop flags control this behavior: These flags are fetched from the server automatically on each connection via fetch_props(). Token resolution uses the LID-to-phone-number cache and the tc_token store — if a valid, non-expired token exists for a participant, it is attached to the IQ request.
Privacy token attachment is fully automatic. You don’t need to call any extra methods or manage tokens manually. If the AB flags are disabled on the server, group operations work exactly as before.
See Client API - AB props cache for more details on experiment flags, and TC Token API for token management.

Addressing modes

Groups can use different addressing modes:
LID (Long ID) mode provides better privacy by hiding phone numbers. The library automatically handles LID-to-phone-number mapping when needed.

Participant response codes

When adding or removing participants, check the response codes:

Error handling

Advanced usage

Handling LID groups

For LID-based groups, you may need phone number mappings:

Participant options

For advanced participant configurations:
See Groups API reference for addressing mode details.

Best practices

1
Validate input before creating groups
2
// ✅ Good: Validate before creation
let subject = match GroupSubject::new(user_input) {
    Ok(s) => s,
    Err(e) => {
        eprintln!("Invalid subject: {}", e);
        return Err(e);
    }
};

// ❌ Bad: No validation
let subject = GroupSubject::new(user_input)?;  // May panic on invalid input
3
Check response codes
4
Always check participant operation responses:
5
let responses = client.groups().add_participants(&group_jid, &participants).await?;

let mut success_count = 0;
let mut failed = Vec::new();

for response in responses {
    if response.status.as_deref() == Some("200") {
        success_count += 1;
    } else {
        failed.push(response);
    }
}

println!("Added {} participants", success_count);
if !failed.is_empty() {
    eprintln!("Failed to add {} participants", failed.len());
}
6
Handle addressing modes
7
Be aware of LID vs PN addressing:
8
let info = client.groups().query_info(&group_jid).await?;

if info.addressing_mode == AddressingMode::Lid {
    // Handle LID-based group
    // Phone numbers may not be directly visible
} else {
    // Handle phone-number-based group
}
9
Cache group information
10
The library automatically caches group info:
11
// First call: fetches from server
let info = client.groups().query_info(&group_jid).await?;

// Second call: uses cache
let info = client.groups().query_info(&group_jid).await?;

Next steps