Button and List messages do not render on consumer WhatsApp — only Carousel works (v0.7.1)
维护者通常 5 天内回复
还没有人认领这个 Issue。
评估
调研方向
从 Evolution GO Manager lab 使用的 /send/button 和 /send/list 入口开始，然后将它们的行为与 v0.7.1 中的 /send/carousel 进行比较。复现 consumer-WhatsApp 矩阵，并检查 server 或 whatsmeow 的 debug 输出中是否有确认或拒绝。完成的标准是确定这是协议限制还是实现 bug，然后记录该限制，或定义所请求的响应警告。
由索引模型根据 Issue 内容生成。
描述
Welcome!
- Yes, I have searched for similar issues on GitHub and found none.
What did you do?
Tested every interactive send endpoint of evolution-go against a personal (non-Business) consumer WhatsApp recipient, using the Evolution GO Manager's per-instance lab modal ("Testar botões, lista e carrossel"), which constructs the official canonical payloads for each variant.
Specifically I ran:
/send/text— plain text (control)/send/button— Reply × 1, Reply × 3 (server max), CTA Copy, CTA URL, CTA Call, PIX alone, CTAs grouped (copy + url + call) → 7 variants/send/list— single sections list → 1 variant/send/carousel— 4 cards REPLY, 4 cards URL, 3 cards CALL, 4 cards COPY → 4 variants
Same sender instance, same recipient phone, runs spread over ~5 minutes.
Reproduction
- Pair an instance with a personal WhatsApp number (not Business / WABA).
- Open the Manager → Instances page → click the "Testar botões, lista e carrossel" lab icon on the instance.
- Enter a personal phone number (not on WABA / Cloud API).
- Run each of the 9 button + list modes one after another.
- Re-run with each of the 4 carousel modes.
- Watch what the recipient phone actually displays.
What did you expect?
I expected all variants to render on the recipient's WhatsApp because:
- The API returned
200 OKwithIsFromMe: trueand a real WhatsApp message ID for every single send (so the sender's session successfully emitted the frame to WhatsApp's servers). - The Manager UI's lab modal explicitly bills itself as a delivery test tool for these endpoints — if these payloads weren't expected to work, they shouldn't be in the lab.
- The plain-text
/send/textcontrol delivered cleanly to the same recipient, so the device + recipient pair is healthy.
What did you observe instead of what you expected?
Only /send/carousel actually delivers usable content to consumer WhatsApp. Every /send/button variant arrives as a placeholder asking the recipient to update WhatsApp, and /send/list does not arrive at all.
| Endpoint | Variant (from Manager UI lab) | API response | Receiver result |
|---|---|---|---|
/send/text |
plain text | 200 OK | ✅ Rendered cleanly |
/send/button |
Reply × 1 | 200 OK | ❌ "Update WhatsApp…" placeholder |
/send/button |
Reply × 3 (server max) | 200 OK | ❌ "Update WhatsApp…" placeholder |
/send/button |
CTA Copy | 200 OK | ❌ "Update WhatsApp…" placeholder |
/send/button |
CTA URL | 200 OK | ❌ "Update WhatsApp…" placeholder |
/send/button |
CTA Call | 200 OK | ❌ "Update WhatsApp…" placeholder |
/send/button |
PIX alone | 200 OK | ❌ "Update WhatsApp…" placeholder |
/send/button |
CTAs grouped (copy + url + call) | 200 OK | ❌ "Update WhatsApp…" placeholder |
/send/list |
Single sections list | 200 OK | ❌ Not delivered at all |
/send/carousel |
4 cards REPLY + image headers | 200 OK | ✅ Renders, all buttons work |
/send/carousel |
4 cards URL | 200 OK | ✅ Renders (URL button serialization is its own issue, see #51) |
/send/carousel |
3 cards CALL | 200 OK | ✅ Renders |
/send/carousel |
4 cards COPY | 200 OK | ✅ Renders |
In every case the API returns 200 with a real message ID — the difference is entirely on the WhatsApp client side.
If this is by design (WhatsApp restricting these frame types for unofficial-API sessions), it would help operators a lot if the README / changelog said so explicitly. Right now the lab modal happily ships these payloads as if they were expected to work for any recipient.
Screenshots/Videos
No response
Which version are you using?
evolution-go v0.7.1 (Docker)
What is your environment?
Docker
If applicable, paste the log output
No response
Additional Notes
Sender / recipient setup
- Sender: personal WhatsApp number connected via QR (not Business)
- Recipient: personal WhatsApp number on Android, current app version, not on Business / WABA / Cloud API
- evolution-go reachable on a public host
- Same sender → same recipient pair for ALL tests in the matrix
Related
- Issue #51 — "Carousel Message Buttons Serialization Bug" — affects URL/CALL/COPY button params inside carousels in v0.7.1.
Questions for maintainers
- Is the button/list non-delivery to consumer WhatsApp a known WhatsApp protocol restriction (e.g. they only accept those frame types from Business-API sessions)?
- If yes — would you consider documenting this in the README and/or returning a warning header on the response (e.g.
X-Whatsapp-Delivery-Risk: high) so callers can surface it to their users? - If no — is there a server log or whatsmeow debug toggle I can enable to capture the WhatsApp ack / rejection for these messages? Happy to run a follow-up test.
Thanks for the project — carousel works reliably and is genuinely useful for our use case.
- 主要语言
- Go
- 星标
- 890
- 派生
- 473
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
evolution-foundation/evolution-go 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 84/100
evolution-foundation/evolution-go#193 ·
维护者通常 5 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
evolution-foundation/evolution-go#104 ·
维护者通常 5 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 74/100
evolution-foundation/evolution-go#101 ·
维护者通常 5 天内回复
-
bug
难度 1/5 1 小时以内 新手友好度 88/100
evolution-foundation/evolution-go#97 · 2 条评论 ·
维护者通常 5 天内回复
-
难度 4/5 3-5 天 新手友好度 48/100
evolution-foundation/evolution-go#204 · 1 条评论 ·
维护者通常 5 天内回复
查看 evolution-foundation/evolution-go 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 90/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
NVIDIA/k8s-device-plugin#2076 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
agentic-workflows
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
area/release kind/bug
难度 2/5 1-3 小时 新手友好度 82/100
kubernetes-sigs/kueue#16455 · 1 条评论 ·
维护者通常 1 天内回复