Missing Event / API Support for WhatsApp Community “Suggested Groups”

[shelomito12]

Summary

There is currently no way in Baileys to detect, intercept, or programmatically manage “suggested groups” within WhatsApp Communities. This creates a significant gap for moderation, automation, and security workflows.

---

Problem Description

In WhatsApp Communities, when the setting “Only admins can add new groups” is enabled:

• Non-admin members cannot directly add groups

• However, they can still suggest groups for admin approval

These suggested groups appear in a pending approval queue in the mobile app UI.

---

Observed Behavior (Baileys)

When a user suggests a group:

• ❌ No groups.upsert event is emitted

• ❌ No groups.update event is emitted

• ❌ No chats.upsert or related event

• ❌ No app-state sync mutation is observed

• ❌ No trace in event logs whatsoever

This has been verified through detailed logging around the exact timestamps of suggestion activity.

---

Important Distinction

Action | Visibility in Baileys -- | -- Suggest group (pending approval) | ❌ Not visible Group approved and linked | ✅ Visible (sometimes via groups.upsert) Participant updates | ✅ Visible (if bot is in group)

This indicates that group suggestions exist only in mobile client UI state and are not propagated through the WhatsApp Web protocol that Baileys relies on.

---

Why This Is a Problem

This limitation prevents developers from:

• Detecting who suggested a group

• Detecting when a group was suggested

• Automatically approving/rejecting suggestions

• Building moderation workflows

• Enforcing policy or governance rules

In practice, this creates a blind spot where:

1. A non-admin suggests a group

2. Admin approves (manually, possibly without full context)

3. Group becomes part of the community

4. Only after this point does Baileys gain visibility

By then, it may already be too late for preventive action.

---

Current Workarounds (Limited)

Developers are forced to rely on post-facto mitigation, such as:

• Listening to groups.upsert

• Fetching metadata via groupMetadata

• Checking metadata.owner

• Removing group via:

  sock.communityUnlinkGroup(groupJid, communityJid)
  

However:

• This only works after approval

• It does not prevent initial exposure

• It introduces latency in enforcement

---

Additional Constraints

• group-participants.update only works if the bot is already inside the group

• There is no way to inspect the pending suggestions queue

• No API exists to:

  • list suggestions

  • approve/reject suggestions

  • subscribe to suggestion events

---

Feature Request

Expose support for Community group suggestions via one or more of the following:

1. Event Emission

A new event such as:

sock.ev.on('community.group.suggested', (data) => { ... })

With payload:

{
  communityJid: string
  groupJid: string
  suggestedBy: string
  timestamp: number
  subject?: string
}

---

2. Suggestion Management API

Methods such as:

sock.communityFetchGroupSuggestions(communityJid)
sock.communityApproveGroupSuggestion(groupJid, communityJid)
sock.communityRejectGroupSuggestion(groupJid, communityJid)

---

3. App-State Exposure

If suggestions are part of internal app-state patches, expose them via:

• app-state.sync hooks

• or a dedicated namespace

---

Expected Impact

Adding this capability would enable:

• Automated moderation systems

• Policy enforcement (e.g. trusted creators only)

• Security controls

• Better observability for community management

• Reduced reliance on manual admin workflows

---

Environment

• Baileys version: latest (as of testing)

• WhatsApp Web protocol via Baileys

• Communities feature enabled

• Setting: “Only admins can add new groups”

---

Closing Notes

This is not a minor edge case—it is a structural limitation affecting any system attempting to build governance or automation on top of WhatsApp Communities.

Currently, there is no way to observe or control group suggestions, which makes it impossible to implement proactive moderation.

---

Would appreciate clarification on whether:

1. This is a known limitation of the WhatsApp Web protocol

2. There are plans to support this in Baileys

3. There are undocumented workarounds or experimental hooks

Thanks.

[shelomito12]

Summary

There is no public API in Baileys to reject (or even just enumerate) community sub-group suggestions — the pre-approval queue that fires created_sub_group_suggestion notifications and is shown in the WhatsApp app under Community → Settings → Pending group suggestions.

I've reverse-engineered the incoming notifications cleanly via sock.ws.on('frame'), but every IQ format I've tried for the outgoing reject either times out or returns an empty <iq type="result"/> that has no effect on the server-side queue. The suggestion stays pending in WA's UI until an admin manually rejects.

The post-approval communityUnlinkGroup API (already in Baileys) works perfectly as a fallback once the suggestion is approved into the community, but we lose the user-facing benefit of stopping the abuse before approval.

Environment

• Baileys version: 7.0.0-rc.9
• Node version: v24.14.1
• WA Web version (via fetchLatestWaWebVersion): 2.3000.1037726364-alpha

What I'm trying to do

For a registered community where non-admins are allowed to suggest groups, auto-reject every suggestion from a non-admin and keep an audit trail. Today we have to manually reject in the mobile/web app, which doesn't scale.

What works (incoming protocol)

I attached a frame listener to sock.ws and identified the following <notification type="w:gp2"> children involved in the suggestion lifecycle. Sample captures (with anonymized JIDs):

created_sub_group_suggestion (when a member suggests a new sub-group)

{
  "tag": "notification",
  "attrs": {
    "type": "w:gp2",
    "from": "<COMMUNITY>@g.us",
    "participant": "<SUGGESTER_LID>@lid",
    "participant_pn": "<SUGGESTER_PHONE>@s.whatsapp.net"
  },
  "content": [
    {
      "tag": "created_sub_group_suggestion",
      "attrs": {},
      "content": [
        {
          "tag": "sub_group_suggestion",
          "attrs": {
            "jid": "<NEW_GROUP>@g.us",
            "creator": "<SUGGESTER_LID>@lid",
            "creator_pn": "<SUGGESTER_PHONE>@s.whatsapp.net"
          }
        }
      ]
    }
  ]
}

revoked_sub_group_suggestions (broadcast to all members when an admin handles the suggestion)

Two reason values observed:

• reason="rejected" — admin tapped Reject in the app
• reason="approved" — admin tapped Approve; followed shortly by a separate <link link_type="sub_group"> notification

{
  "tag": "revoked_sub_group_suggestions",
  "attrs": {},
  "content": [
    {
      "tag": "sub_group_suggestion",
      "attrs": {
        "jid": "<GROUP>@g.us",
        "creator": "<SUGGESTER_LID>@lid",
        "creator_pn": "<SUGGESTER_PHONE>@s.whatsapp.net",
        "reason": "rejected"
      }
    }
  ]
}

link link_type="sub_group" (when the admin approves a suggestion → group becomes a sub-group of the community)

{
  "tag": "link",
  "attrs": { "link_type": "sub_group" },
  "content": [
    { "tag": "group", "attrs": { "jid": "<GROUP>@g.us", "subject": "Group Name" } }
  ]
}

What does NOT work (outgoing IQ to reject)

I've tried several IQ shapes, all to xmlns="w:g2", type="set", to="<COMMUNITY>@g.us". None produce an effect on the server's pending queue.

Attempt 1 — sub_group_suggestions_action wrapper (mirrors membership_requests_action pattern)

await sock.query({
  tag: 'iq',
  attrs: { type: 'set', xmlns: 'w:g2', to: communityJid },
  content: [{
    tag: 'sub_group_suggestions_action',
    attrs: {},
    content: [{
      tag: 'reject',
      attrs: {},
      content: [{ tag: 'sub_group_suggestion', attrs: { jid: suggestedGroupJid } }],
    }],
  }],
});

Outcome: WA usually returns an empty <iq type="result"/> (no echoed body, no error code). The suggestion stays in the queue. Sometimes the request times out at 60s with no response at all, even though socket health is otherwise fine.

Attempt 2 — revoke_sub_group_suggestions (mirroring the broadcast tag)

await sock.query({
  tag: 'iq',
  attrs: { type: 'set', xmlns: 'w:g2', to: communityJid },
  content: [{
    tag: 'revoke_sub_group_suggestions',
    attrs: {},
    content: [{
      tag: 'sub_group_suggestion',
      attrs: {
        jid: suggestedGroupJid,
        creator: suggesterLid,   // the LID we got from `created_sub_group_suggestion`
        reason: 'rejected',
      },
    }],
  }],
});

Outcome: Times out every time. Real production log line:

[LocalGroups] Reject IQ response for <GROUP>@g.us @ <COMMUNITY>@g.us (creator=<SUGGESTER_LID>@lid): (timeout, no response)
[LocalGroups] Reject IQ failed (attempt 1/3) for row 2 (<GROUP>@g.us): IQ timeout (no response)

Attempt 3 — revoke_sub_group_suggestions (singular, no s)

content: [{
  tag: 'revoke_sub_group_suggestion',  // singular
  attrs: {},
  content: [{ tag: 'sub_group_suggestion', attrs: { jid } }],
}]

Outcome: Times out.

Things I have not yet tried (would love guidance on)

• A <sub_group_suggestion_action action="reject"> form (single element, attribute-driven).
• A <remove_sub_group_suggestion/> form (parallel to <remove> for participants).
• A GET query for the suggestion list (e.g. <sub_group_suggestions/>) — does that namespace exist?
• An IQ addressed to the suggested group's JID instead of the community.
• Different xmlns (e.g. w:gp2 instead of w:g2).

What works as a fallback (post-approval)

sock.communityUnlinkGroup(suggestedGroupJid, communityJid) works perfectly after an admin approves the suggestion and the link sub_group notification fires. So I built a post-approval safety net: when a non-admin's suggestion gets approved, I auto-unlink immediately. This succeeds every time, but it's not user-facing-clean (the group flashes into the community before being kicked back out) and it requires admin approval to ever fire.

Reproduction steps

1. Create a community with allow_non_admin_sub_group_creation = true (default for new communities).
2. Connect to WA Web with Baileys 7.0.0-rc.9 as an account that is admin of the community.
3. From a different account, suggest a new group to that community via the WhatsApp mobile UI.
4. Observe created_sub_group_suggestion notification reach the bot.
5. Try any of the IQ shapes above to reject. Observe either silent no-op (<iq type="result"/> with the queue unchanged) or 60s timeout.

Asks

1. Is created_sub_group_suggestion something Baileys plans to officially support? It's clearly part of w:gp2.
2. Could a maintainer or community member with access to Chrome DevTools while using WhatsApp Web capture the outgoing iq frame when manually clicking Reject on a pending group suggestion? That would settle the format question conclusively.
3. If this is intentionally not exposed by the WA Web client (only Android/iOS), a not-implemented/feature-not-supported reply would at least let me skip the timeout. The fact that one variant returns an empty 200 instead of an error suggests the format is almost right.

Code snippets

The full deep-frame sniffer + reject helper as I have them today:

// Sniffer (sock.ws.on('frame'))
sock.ws.on('frame', (frame) => {
  if (frame?.tag !== 'notification' || frame.attrs?.type !== 'w:gp2') return;
  for (const child of frame.content || []) {
    if (child.tag === 'created_sub_group_suggestion') {
      // see incoming frame example above
    }
    if (child.tag === 'revoked_sub_group_suggestions') {
      // see incoming frame example above
    }
  }
});

// Reject (current best guess — still doesn't actually reject)
async function rejectGroupSuggestion(sock, communityJid, suggestedGroupJid, suggesterLid) {
  return sock.query({
    tag: 'iq',
    attrs: { type: 'set', xmlns: 'w:g2', to: communityJid },
    content: [{
      tag: 'revoke_sub_group_suggestions',
      attrs: {},
      content: [{
        tag: 'sub_group_suggestion',
        attrs: { jid: suggestedGroupJid, creator: suggesterLid, reason: 'rejected' },
      }],
    }],
  });
}

Happy to share full deep-dumped frame captures if useful — I have a JSONL file of every w:gp2 notification observed.

What I changed in the code (this round)

      const _serializeContent = (content) => {
        if (!content) return null;
        if (Array.isArray(content)) return content.map(c => ({ tag: c?.tag, attrs: c?.attrs, hasContent: !!c?.content }));
        if (content instanceof Uint8Array) return `(${content.length} bytes)`;
        return String(content);
      };

      const _serializeNodeDeep = (node, depth = 0, maxDepth = 8) => {

• New _serializeNodeDeep — recursive, captures every nested level (up to depth 8).
• New _walkAttrIndex — climbs the entire tree and indexes every attr by name with its path (e.g. attrIndex.jid = [{ path: "/created_sub_group_suggestion/sub_group_suggestion", value: "..." }]). This is the safety net you asked about: if WA ever moves jid (or adds a new field like creation, signature, etc.) to a different node, we'll see it without needing to update the parser.
• The created_sub_group_suggestion and revoked_sub_group_suggestions handlers now both:
  • Run the deep dump
  • Try the existing surface-level extraction first
  • Fall back to the attrIndex to find jid/subject/creator_pn anywhere in the tree
  • Append the full capture (raw deep tree + attrIndex) to a new file data/suggestion-captures.jsonl
  • Log [Protocol Discovery] created_sub_group_suggestion FULL: … at info level so PM2 logs show every field
• Same upgrade applied to the unknown-tag discovery branch — earlier captures had empty childAttrs because we only stringified one level; now every unknown tag gets full nested capture.
• Added mkdirSync('data', { recursive: true }) guard so the file write never silently fails on a fresh checkout.

After the next test, paste me the [Protocol Discovery] created_sub_group_suggestion FULL: … line and the corresponding revoked_sub_group_suggestions FULL line (when an admin manually rejects a pending suggestion). If WA's notification carries any field we've been ignoring (e.g. a creation timestamp, a signature, or a nested metadata node), the IQ likely needs to echo it back — and the new logs will surface it. Without those, the GitHub issue is the right next step; one of the maintainers or someone with WA Web DevTools access can answer the format question definitively.

[shelomito12]

Update — May 7, 2026: Deep frame capture + rc10 + complete IQ attempt history

Posting a comprehensive update with all our findings since opening this issue. We upgraded to Baileys 7.0.0-rc10 and added a recursive frame sniffer that dumps the full node tree on every suggestion event. This has given us the clearest picture yet of the protocol — and definitively isolated the problem to the outgoing IQ, not parsing.

---

What we built on the receiving side (all working perfectly)

We attached a sock.ws.on('frame') listener that fires on every <notification type="w:gp2"> and specifically handles four children:

Tag	Direction	Status
created_sub_group_suggestion	Inbound	✅ Detected, fully parsed
revoked_sub_group_suggestions	Inbound	✅ Detected, reason extracted
link with link_type="sub_group"	Inbound	✅ Detected (approval confirmed)
unlink with unlink_type="sub_group"	Inbound	✅ Detected (removal confirmed)

---

Confirmed frame structure (rc10, two fresh captures)

created_sub_group_suggestion

{
  "tag": "notification",
  "attrs": {
    "type": "w:gp2",
    "from": "120363100000000001@g.us",
    "participant": "109000000000001@lid",
    "participant_pn": "15550001234@s.whatsapp.net"
  },
  "content": [
    {
      "tag": "created_sub_group_suggestion",
      "attrs": {},
      "content": [
        {
          "tag": "sub_group_suggestion",
          "attrs": {
            "jid": "120363200000000001@g.us",
            "creator": "109000000000001@lid",
            "creation": "1778173426",
            "creator_pn": "15550001234@s.whatsapp.net"
          },
          "content": [
            {
              "tag": "subject",
              "attrs": {},
              "content": { "_bytes": 18 }
            }
          ]
        }
      ]
    }
  ]
}

Note: The group subject is in a nested <subject> child as raw bytes (UTF-8 encoded), not an attribute. Buffer.from(subjectNode.content).toString('utf-8') decodes it correctly. Earlier parsing attempts against attrs.subject always returned null because no such attr exists.

revoked_sub_group_suggestions (emitted when admin manually rejects from the app)

{
  "tag": "notification",
  "attrs": {
    "type": "w:gp2",
    "from": "120363100000000001@g.us",
    "participant": "274000000000001@lid",
    "participant_pn": "15559876543@s.whatsapp.net"
  },
  "content": [
    {
      "tag": "revoked_sub_group_suggestions",
      "attrs": {},
      "content": [
        {
          "tag": "sub_group_suggestion",
          "attrs": {
            "jid": "120363200000000001@g.us",
            "reason": "rejected",
            "creator": "109000000000001@lid",
            "creator_pn": "15550001234@s.whatsapp.net"
          }
        }
      ]
    }
  ]
}

Note: creation timestamp is present on the inbound suggestion but absent from the revoke broadcast. The reason field is "rejected" for manual rejection and "approved" when the admin approves.

---

Full attr index from _walkAttrIndex (exhaustive tree traversal)

To make absolutely sure we aren't missing a field at any nesting depth, we ran a recursive attr indexer. Every attr name that appeared anywhere in the tree:

For created_sub_group_suggestion: jid, creator, creation, creator_pn
For revoked_sub_group_suggestions: jid, reason, creator, creator_pn

No signature, nonce, token, metadata, key, or any hidden field at any depth. The structure is exactly what it looks like at first glance.

---

All outgoing IQ shapes attempted — all failed

All sent via sock.query(), xmlns: 'w:g2', type: 'set', to: '<COMMUNITY>@g.us'.

Attempt 1 — sub_group_suggestions_action/reject (modeled on membership_requests_action)

content: [{
  tag: 'sub_group_suggestions_action',
  attrs: {},
  content: [{
    tag: 'reject',
    attrs: {},
    content: [{ tag: 'sub_group_suggestion', attrs: { jid: suggestedGroupJid } }],
  }],
}]

Outcome: Received <iq type="result"/> with empty body — no error, no effect. Suggestion remained in WA UI queue. Classic silent 200.

Attempt 2 — revoke_sub_group_suggestions without creator (same tag as broadcast)

content: [{
  tag: 'revoke_sub_group_suggestions',
  attrs: {},
  content: [{ tag: 'sub_group_suggestion', attrs: { jid: suggestedGroupJid, reason: 'rejected' } }],
}]

Outcome: 60-second timeout, no response from server.

Attempt 3 — revoke_sub_group_suggestions with creator LID (closest match to the inbound broadcast)

content: [{
  tag: 'revoke_sub_group_suggestions',
  attrs: {},
  content: [{
    tag: 'sub_group_suggestion',
    attrs: {
      jid: suggestedGroupJid,
      creator: suggesterLid,    // the LID from the `created_sub_group_suggestion` notification
      reason: 'rejected',
    },
  }],
}]

Outcome: 60-second timeout consistently on every test. Real production log:

[LocalGroups] Reject IQ response for 120363200000000001@g.us @ 120363100000000001@g.us
              (creator=109000000000001@lid): (timeout, no response)
[LocalGroups] Reject IQ failed (attempt 1/3) for row 3 (120363200000000001@g.us): IQ timeout (no response)

The timeout pattern (vs. the silent-200 from Attempt 1) is interesting — it suggests the server recognizes the tag but is refusing to process it, rather than routing it to an unknown handler.

---

What works perfectly: post-approval communityUnlinkGroup

Because pre-approval rejection fails, we built a post-approval safety net: when we receive a link sub_group notification for a group that we know was suggested by a non-admin, we call sock.communityUnlinkGroup(groupJid, communityJid) immediately. This succeeds every time (~1 second end-to-end):

17:04:15.195  Sub-group linked: group=120363200000000001@g.us, subject="Group Name v.6", community=120363100000000001@g.us
17:04:15.198  Non-admin suggestion 120363200000000001@g.us got APPROVED — auto-unlinking
17:04:15.675  revoked_sub_group_suggestions received: reason=approved (WA broadcast for the approval)
17:04:16.150  Sub-group unlinked: group=120363200000000001@g.us, by=90000000000001:11@lid (bot)

So the group was live in the community for under 1 second before the bot kicked it back out.

---

Things not yet tried (would love input on)

1. not_allow_non_admin_sub_group_creation setting — send communitySettingUpdate(communityJid, 'not_allow_non_admin_sub_group_creation') to disable suggestions entirely at the community level, rather than rejecting one at a time. This is a blunt instrument but would be effective. Unsure if it's reversible per-user or community-wide only.

2. xmlns: 'w:gp2' — the notifications arrive under w:gp2; maybe the outgoing IQ for suggestions also belongs to that namespace rather than w:g2.

3. IQ addressed to the suggested group's JID — try to: suggestedGroupJid instead of to: communityJid.

4. Fetch the pending queue first — something like { tag: 'sub_group_suggestions', attrs: {} } as a type: 'get' IQ to the community. If WA returns data, that confirms the namespace and shapes the set IQ.

5. creation attribute on the outgoing IQ — even though revoked_sub_group_suggestions doesn't carry creation, the server might use it as a CSRF-style nonce when accepting the corresponding set IQ. We have the timestamp from the inbound notification.

---

Key question for maintainers

The revoke_sub_group_suggestions tag we're sending in Attempt 3 is identical in structure to what WA broadcasts when a human admin rejects (just the direction is reversed). The fact that Attempt 1 returns a silent 200 and Attempt 3 times out suggests the server is doing routing-level filtering on this tag — possibly based on whether the session has a valid TC Token or some account-level entitlement.

Could someone with access to a real WhatsApp Web session and traffic inspection (or Bartender) capture the actual outgoing <iq> frame when clicking "Reject" on a pending group suggestion in the WA Web UI? That single data point would settle the format question definitively.

Alternatively — is communityRejectGroupSuggestion something planned for Baileys? Given the communityUnlinkGroup / communityLinkGroup API surface already exists in communities.js, this would be a natural complement.

---

Workaround summary for anyone hitting this

Until a first-class API exists, communityUnlinkGroup after a link sub_group notification is a reliable ~1-second post-approval remediation. Not ideal, but it works. Detection of the suggestion itself (pre-approval) is possible via sock.ws.on('frame') — full sniffer code available in the comments if useful.

[github-actions]

This issue is stale because it has been open for 14 days with no activity. Remove the stale label or comment or this will be closed in 14 days.

[github-actions]

This issue is stale because it has been open for 14 days with no activity. Remove the stale label or comment or this will be closed in 14 days.

[github-actions]

This issue is stale because it has been open for 14 days with no activity. Remove the stale label or comment or this will be closed in 14 days.