Send text & template
send_text and send_template methods call the Graph API messaging endpoint and return a provider message ID when the client is configured.
WhatsApp Business API
Wavy's backend includes a Meta WhatsApp Business Cloud API client, webhook receiver, template submission, and message-status tracking. The source path exists, but sending real messages requires a registered WABA, a phone-number ID, a server-configured access token, and verified webhooks. Without those, the client reports an unconfigured state and runs in dry-run mode.
How the connection works
This is the real path in the codebase — not a marketing summary. Each step maps to a backend route or service method.
/api/v1/channels route owns this. It does not store your Meta access token — that remains a server environment variable.WhatsAppClient reads META_PHONE_NUMBER_ID and META_ACCESS_TOKEN from deployment settings. A self-service per-workspace credential vault is not implemented; do not paste access tokens into chat or ordinary form fields./webhooks/meta endpoint for inbound messages and status receipts. The verifier uses constant-time HMAC comparison against an app secret. When the app secret is absent, verification is lenient for development only — it is not safe for production.send_text or send_template. The response carries a provider message ID. Status receipts (queued, sent, delivered, read, failed) arrive via webhook and update the message record.What you need
These are Meta's and the codebase's real prerequisites — not a checklist we invented.
META_ACCESS_TOKEN and META_PHONE_NUMBER_ID are required for the client to report configured. META_APP_SECRET is required for production webhook signature verification, and META_WABA_ID is required for template listing and submission.app_secret must be configured for production-grade signature verification.Safeguards
These are built-in safety behaviours, not promises.
What the API path covers
send_text and send_template methods call the Graph API messaging endpoint and return a provider message ID when the client is configured.
A /webhooks/meta route receives inbound messages and status updates, verifies signatures, and persists them to the conversation and message tables.
Templates are created locally, submitted to Meta, and tracked through PENDING → APPROVED / REJECTED. Only APPROVED templates are campaign-eligible.
Receipts from Meta update each message's status. The workspace inbox shows queued, sent, delivered, read, and failed as distinct states.
Unconfigured sends return a synthetic ID and do not call Meta. This keeps local development and unconfigured deployments from masquerading as live sends.
Questions
No. Automix is not a BSP. You register and verify your own WABA and phone number with Meta, then configure the server credentials. Wavy provides the client and workflow, not the Meta account.
Not without provider setup. The backend path exists, but live sends require a registered WABA, a phone-number ID, a server-configured access token, and a verified webhook. Until those are in place, the client runs in dry-run mode.
In the server environment as a deployment setting. A self-service per-workspace credential vault is not implemented. Do not paste access tokens into chat or ordinary form fields.
The WhatsAppClient reports an unconfigured state and returns a synthetic message ID. No call is made to Meta. This is intentional so that development and unconfigured deployments do not appear to send live messages.
No. Wavy submits templates to Meta and tracks their status, but Meta governs approval, display-name changes, and policy enforcement. Automix does not claim to guarantee approval or manage your Meta policy standing.
Only when the app secret is configured. The verifier uses constant-time HMAC comparison. When the app secret is absent, verification is lenient for development only and the system is not safe for production traffic.
The API path is wired in and workspace-scoped. Live messaging starts when your Meta credentials and webhook are configured.