[Feature Request] - broadcast list

[devlikepro]

We need to check broadcast list in WEBJS and NOWEB

---

Hello,

We recently acquired an important client who requires sending 14,000 messages. Currently, we have set up a sending interval of 30 seconds to 1 minute, which would make this a very lengthy process to handle such a volume.

We were considering using broadcast lists, but we are concerned that WhatsApp might block the number, and we have not found this feature in Waha.

Could you suggest any other solutions to manage this volume of messages more efficiently?

Thank you very much.

Originally posted by @paeconsultoria in #463

[JJhooww]

Being able to add, remove and manage list members can be a great alternative to preventing you from spamming to notify multiple customers. This is definitely a good approach.

[mateo19182]

I would also be very interested in this feature, any updates?

[alessandrovolpin]

+1

[tangjiachao]

+1

[washingtong33k]

That would be great

[ADAMAYAMEOGO]

Hi! I looked into this for the GOWS engine, and most of the stack already supports it:

• In the whatsmeow fork used by GOWS (devlikeapro/whatsmeow @ 8c86cdb), SendMessage to any @broadcast JID uses SendRequestExtra.Participants when they are provided (the change from status: Add req.Participants for Status message tulir/whatsmeow#800). It only falls back to getBroadcastListParticipants, which returns ErrBroadcastListUnsupported for non-status lists, when no participants are given.
• In gows-plus, server/messages.go already maps MessageRequest.participants to extra.Participants, and GoWS.SendMessage only special-cases status@broadcast: any other @broadcast JID goes straight to Client.SendMessage.
• The missing piece is in WAHA: sendText and the media senders for GOWS never pass participants, so a request to <id>@broadcast fails with "sending to non-status broadcast lists is not yet supported".

Proposal: add an optional participants field to the send-message requests, accepted only when chatId is a non-status broadcast JID, and forward it to GOWS. The message is then sent once to the list JID and fanned out by WhatsApp, like on the phone, instead of N individual messages. Other engines would return a clear "not supported" error for now (current Baileys code treats non-status broadcast JIDs like 1:1 chats).

Before opening a PR, I'd test two things: whether the server accepts a phone-created list JID when sending from a linked device, and how to discover the phone's lists (IDs and members), which I haven't seen synced to linked devices so far.

I'm happy to open a PR for this. Would you accept it, and do you prefer a participants field on the existing send endpoints or a dedicated endpoint?

[ADAMAYAMEOGO]

Update: sending to phone-created broadcast lists works with GOWS, tested on personal and Business accounts. Two PRs: devlikeapro/whatsmeow#1 (sender key rotation, needed for the phone to show the messages) and #2288 (the participants field). Details in the PRs.