| name | whatsapp-delivery |
| description | WhatsApp channel specialist workflow: debug Meta webhook verification/signatures, link-state projection, /whatsapp-webhook fast path, boot messages, and adapter delivery. |
WhatsApp Delivery
Use after channel-debug-core for WhatsApp issues.
Files
src/app/api/channels/whatsapp/webhook/route.tssrc/server/channels/whatsapp/**src/server/workflows/channels/drain-channel-workflow.tssrc/server/admin/why-not-ready.tssrc/app/api/channels/summary/route.ts
Runtime Path
Meta webhook verification GET OR message POST -> app route -> x-hub-signature-256 validation -> dedup -> fast path to port 3000 /whatsapp-webhook OR workflow -> WhatsApp adapter/API reply
Parallel Lane Inputs To Consume
Before proposing a WhatsApp fix, consume:
- Vercel/app logs lane: GET verification vs POST delivery, signature result, requestId/deliveryId/Meta message ID, and project targeting proof.
- Sandbox runtime lane: port 3000 listener and
/whatsapp-webhook behavior, sanitized config has channels.whatsapp.
- Workflow lane: workflow start/run/forward state when fast path skipped or failed, with verified project targeting when
.vercel/project.json differs from the incident target.
- Prior-fix comparison: linkState projection mistaken as delivery, status-only skip, boot message send/delete, handler non-OK classification.
Special Checks
- GET verification and POST delivery are different paths.
linkState is not the same as user-visible reply.- Meta signature validation depends on raw body.
- Handler non-OK may still prove handler receipt; classify precisely.
- Boot message send/delete behavior affects user-visible state.
lastForward must reflect fast-path failure as well as success.
