Hook for join requests in a group I admin?

[nirizr]

Hey!

I'm moving from raw whatsapp web js to OpenWA and I'm porting my APIs clients.
In wweb JS there's a group_membership_request hook event that lets an account know when a request to join a group is added.

Is there something similar in OpenWA? I tried searching online and reading the documentation but couldn't find anything.
Also, after that I would like to approve or reject join requests through the API and I couldn't find that either.

[rmyndharis]

Hi @nirizr — thanks for the clear question, and you read the docs correctly: at the time you asked, OpenWA had neither the event nor the endpoints. Both exist now, on main (#1174). They are not in a release yet — the newest tag is v0.14.6, which predates them, so everything below describes main.

The event — subscribe to group.join_request on a webhook or the socket. It fires when someone asks to join a group the session administers. The webhook body is the usual envelope, and the group fields arrive under data:

{
  "event": "group.join_request",
  "timestamp": "2026-08-09T09:00:00.000Z",
  "sessionId": "…",
  "idempotencyKey": "…",
  "deliveryId": "…",
  "data": {
    "groupId": "120363000000000000@g.us",
    "participantIds": ["628123456789@c.us"],
    "timestamp": 1754700000,
    "actorId": "628987654321@c.us"
  }
}

That data shape is the same dialect as the other group.* events. participantIds are the users asking to join. actorId is who created the request and is present only when the engine reports one — it differs from the requester on a non-admin add. On whatsapp-web.js this sits on the group_membership_request hook you're migrating from (a notification carrying no group or requester id is dropped as unactionable, otherwise it passes straight through).

One engine caveat, documented rather than papered over: on the Baileys engine the library (7.0.0-rc13) emits its join-request event only for non-admin-add requests, so an invite-link self-request may not produce an event there. The list endpoint below still reports those requests either way, so polling it covers the gap if you run Baileys.

The API — three routes under the session's group resource:

• GET /api/sessions/:sessionId/groups/:groupId/membership-requests — the pending queue. Each entry carries participantId, plus method (invite_link / non_admin_add / linked_group_join) and requestedAt when the engine reports them, and addedById on whatsapp-web.js (the Baileys list does not carry it). Fields the engine does not report are omitted rather than defaulted. Any valid API key works.
• POST .../membership-requests/approve
• POST .../membership-requests/reject

Both writes take {"participants": ["628123456789@c.us"]} to act on named requesters, or an empty body to act on every pending request, and require an OPERATOR-role key. The response is { success, message, results }, where results holds one entry per participant — a partial refusal stays visible there instead of being flattened into a blanket success, and acting on an empty queue is a no-op that returns an empty list.

Full reference on main: docs/06-api-specification.md → the three routes under 6.4.4 Groups, and group.join_request in the webhook event catalog further down the same file.