buddyboss/send-message sends a private message. Pass recipients to start a new thread, or thread_id to reply into an existing one.
There is no recall.
At a glance
| Ability | buddyboss/send-message |
| Toolset | BuddyBoss — toolset/buddyboss |
| Group | BuddyBoss › Messages |
| Requires | AcrossAI Pro, plus BuddyBoss Platform active on the site |
| Capability | manage_options |
| Safety | Writes data |
| Repeatable | Not idempotent — each call changes the row set, so re-running is not a no-op |
| Ships in | AcrossAI Pro 0.9.16 and later |
Sent is sent
This cannot be undone. The message lands in real inboxes and usually sends email, and deleting the thread later removes it from the sender’s view but not from the recipients’. sender_id makes the message appear to come from that member with nothing to indicate an administrator wrote it — use it deliberately. The response always reports who the message was attributed to.
How it works
The message arrives in the recipients’ mailboxes and, on most sites, generates email. Deleting the thread afterwards removes it from one participant’s mailbox — not from everybody’s, and not from the email that already went.
So the usual mitigations for a mistaken write do not apply here. The only real control is before the send.
sender_id is the parameter to be deliberate about. It attributes the message to that member, and nothing in the message indicates an administrator wrote it — the recipient sees a message from their colleague.
There are legitimate uses for that, and there are obvious ways to misuse it. The response always reports who the message was attributed to, so the record is unambiguous either way.
Use buddyboss/search-recipients first: it resolves names to IDs and establishes whether the message can be delivered at all.
Not idempotent — each call sends.
Input
| Name | Type | Required | What it is |
|---|---|---|---|
recipients | array | For a new thread | Member IDs to send to. |
thread_id | integer | For a reply | The thread to reply into. |
subject | string | No | The subject, for a new thread. |
content | string | Yes | The message. |
sender_id | integer | No | Attribute the message to this member. Nothing indicates an administrator wrote it. |
What comes back
| Name | Type | What it is |
|---|---|---|
thread_id | integer | The thread the message landed in. |
attributed_to | integer | Who the message appears to be from. |
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:
Send a message to the group organisers.
It resolves to one call:
{
"ability": "buddyboss/send-message",
"parameters": {
"recipients": [44, 51],
"subject": "Maintenance on Monday",
"content": "The site will be down between 02:00 and 04:00."
}
}Worth knowing
- No recall. Deleting the thread does not remove it from recipients.
- Email usually goes as well as the in-site message.
sender_idimpersonates. The response records who it was attributed to.- Check reachability first — restricted messaging is common.
Related abilities
- BuddyBoss Search Message Recipients — check before sending
- BuddyBoss Get Message Thread — read the thread first
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category