Avox API Go-Live Checklist

Everything to check before sending real customer traffic through the Avox API - number, account, keys, code, statuses, and WhatsApp's own rules.

Work through this list before your integration sends real customer messages. Each item links to the page with the detail.

Your number and account#

• The number shows Connected. On Connections, the number's status is Connected, and on Health, Check health now reports "Can send messages" with no issues.
• Your plan is active and includes API access. Without an active plan, every send fails with subscription_inactive; on a plan without API access, with api_not_in_plan. See Billing and Plans.
• The display name is approved and is the name you want customers to see. See Display names.
• Templates are approved for every message your system starts - order updates, reminders, codes - in every language you'll send. See Templates and Template approval.
• You have the customer's opt-in to receive WhatsApp messages from you, as WhatsApp's policies require.
• Critical alerts reach someone. On Compliance, keep WhatsApp account alerts on, so your team is emailed when Meta sends an account alert or a template is rejected, paused or disabled.

Your keys#

• A dedicated live key per system, created by an Admin in Settings > API Keys with Live key chosen. See Authentication.
• Production uses the live key. A test key (avx_test_...) answers 200 but never sends. Check your production responses don't carry Avox-Test-Mode: true. See Testing.
• Stored as a server secret - environment variable or secrets manager, never in a browser, an app, or a repository.
• Test passes on the key: "Working - routes to" the right number. See Testing.
• Old and test keys are revoked once nothing uses them. Keep a test key only if your CI still uses it.
• A rotation plan your team has written down: Rotate, pick a grace period, deploy the new key, then check on the API logs that the old key has gone quiet. See Rotating a key.
• IP restriction (optional). If your servers have fixed addresses, ask Support to limit the key to them.

Your sending code#

• Branches on error.code, not on the message text or the status alone. See API errors.
• Sends an Idempotency-Key - one per message, reused on every retry of that message. See Idempotency.
• Retries only what's retryable, honouring Retry-After and backing off with jitter. See Rate limits.
• Handles meta_unavailable deliberately - the message may already be out.
• Logs X-Request-Id (or error.request_id) for every failed call, so Support can find it.
• Stores message_id for every success, so statuses and replies can be matched to it.
• Sends templates to start conversations and other types only inside the 24-hour window. See Messaging window.
• Uses full international numbers in to, with the country code.
• Paces bulk sends through a queue instead of firing them all at once.
• Has a timeout on each HTTP call, so a slow network can't hang a worker.

Statuses and replies#

• Someone checks delivery. Logs shows the sent, delivered, read and failed statuses of your API messages. See Delivery statuses and replies.
• biz_opaque_callback_data is set on important sends, so a status is easy to tie to your own record.
• Replies have an owner. Customer replies arrive in the Inbox - decide who on your team answers them, and set up Automation for common questions.
• Failed statuses are reviewed, including codes WhatsApp reports after accepting a message. See Meta error codes.
• If your server receives messages, message forwarding points at your production Endpoint URL, your server checks the Avox-Signature header with the current signing secret, and Send test event shows Delivered. See Receive messages.

WhatsApp's own limits#

• You know your messaging limit. New numbers start with a limit on how many people they can start conversations with each day. It shows as Messaging tier on Health once Meta reports it. See Quality and limits.
• You ramp up gradually rather than sending your whole list on day one.
• Someone watches quality. A drop in quality can lower your limit and pause templates. Health shows Quality history and the delivery rate.

On launch day#

1. 1

   Start small

   Send to a small group first and watch the results for an hour.
2. 2

   Watch the API logs

   Open API logs, pick your live key and choose Error in the status filter to spot unexpected error codes. Each code links to its fix on API errors.
3. 3

   Watch delivery

   On Health, check the delivery rate holds steady.
4. 4

   Watch for key warnings

   In Settings > API Keys, check no key shows a warning such as Requests are failing or Hit its per-minute limit.
5. 5

   Then scale

   Increase volume step by step, keeping an eye on Quality history.

Last updated 15 October 2026