[Feature] Send poll votes and event RSVPs from the API (Baileys) #2776

Welcome!

• Yes, I have searched for similar requests on GitHub and found none.

What type of feature?

Endpoint

What is the motivation for the request?

Evolution can already create polls (/message/sendPoll) and read/decrypt poll votes (/chat/getPollVote, added in #2297), and it receives pollUpdateMessages on webhooks (see #1644, #1008). There is no way to cast a vote, and no way to answer (RSVP) a WhatsApp event message.

The workaround people use is sending a reaction or a text reply. That is not a vote: WhatsApp clients don't count it in the poll results, and the poll creator can't see it as a vote.

WhatsApp encrypts poll votes and event responses with the original message's messageSecret. Baileys can decrypt them (decryptPollVote), but it has no helper that encrypts them. API users can't build these messages themselves.

Usage Examples

• Bots or automations that take part in group polls (scheduling, "who's in?", attendance).
• Answering event invitations (Going / Maybe / Not going) from a CRM or assistant.
• Voting on a poll sent from the same account (self-chat / own polls), e.g. confirmation flows.

POST /message/sendPollVote/{instance}
{ "key": { "remoteJid": "1203...@g.us", "id": "3EB0...", "fromMe": false }, "options": ["Option A"] }

POST /message/sendEventResponse/{instance}
{ "key": { "remoteJid": "1203...@g.us", "id": "3EB0..." }, "response": "going", "extraGuestCount": 0 }

How should the feature be developed?

Implement it directly in the Baileys channel, following the existing sendPoll / sendReaction pattern across DTO → JSON Schema → controller → router → BaileysStartupService. The Meta Business API and Evolution channels throw BadRequestException('Method not available ...'), as they already do for pollMessage.

• The creation message and its messageSecret are loaded from the Message table, scoped by instanceId.
• Encryption mirrors Baileys' decryptPollVote and whatsmeow's encryptMsgSecret: HMAC-SHA256 key derivation over messageId + creatorJid + voterJid + useCase, then AES-256-GCM with AAD messageId\0voterJid.
• Optional jidMode: auto | lid | pn (default auto). In auto mode the LID domain is used when the chat uses LID addressing, and the own LID is used for fromMe messages.
• No database migration and no new dependency. The change is additive and non-breaking.

I have a working implementation on develop and can open a PR if maintainers agree with the approach.

Additional Notes

If you'd prefer the poll-vote endpoint under /chat next to getPollVote instead of /message, I'm happy to move it.