buddyboss/manage-membership-requests handles requests from members to join a group.
That is the opposite direction from buddyboss/manage-group-invites, which is the group inviting members.
At a glance
| Ability | buddyboss/manage-membership-requests |
| Toolset | BuddyBoss — toolset/buddyboss |
| Group | BuddyBoss › Groups |
| Requires | AcrossAI Pro, plus BuddyBoss Platform active on the site |
| Capability | manage_options |
| Safety | Writes data |
| Repeatable | Idempotent — running it twice leaves the same result |
| Ships in | AcrossAI Pro 0.9.16 and later |
How it works
Only private groups produce requests. Public groups are joined directly and hidden groups are invitation-only, so an empty queue on either is expected rather than meaningful.
Knowing that saves a particular confusion: an administrator checking why nobody is requesting to join a public group is looking for something that cannot exist.
list shows who is waiting, approve admits them, reject declines.
Approving joins the member immediately. Unlike accepting an invitation, this is not consuming somebody else’s decision — they asked — which makes it the less fraught of the two approval actions.
Rejecting does not stop them asking again. Banning does, and that is buddyboss/manage-group-membership.
Idempotent.
Input
| Name | Type | Required | What it is |
|---|---|---|---|
group_id | integer | Yes | The group. |
action | string | Yes | list, approve or reject. |
user_id | integer | For approve and reject | The requesting member. |
What comes back
| Name | Type | What it is |
|---|---|---|
requests | array | Who is waiting, for list. |
success | boolean | Whether the call completed. |
message | string | A one-line summary of what happened, suitable for showing a human. |
error_code | string | Present only on failure — a stable machine-readable reason, such as a missing field, a wrong field type or an unmet confirmation. |
Example
Ask your assistant:
Who wants to join the mentors group?
It resolves to one call:
{
"ability": "buddyboss/manage-membership-requests",
"parameters": {
"group_id": 12,
"action": "list"
}
}Worth knowing
- Only private groups produce requests. Empty on public and hidden groups is correct.
- Approving admits immediately.
- Rejecting does not prevent another request. Banning does.
- Idempotent.
Related abilities
- BuddyBoss Manage Group Invites — the other direction
- BuddyBoss Manage Group Membership — ban a repeat requester
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category