Follow Avox Docs on Google
Pick Avox Docs as a preferred source and Google shows these pages more often when you search for help with Avox.
Follow Avox Docs on Google
Pick Avox Docs as a preferred source and Google shows these pages more often when you search for help with Avox.
A live Flow gets data while the customer fills it in: the free times for the day they picked, a price for the cover they chose, whether you deliver to their pincode, whether their coupon still works. It can also save what they give you straight into a table: a booking, a registration, a lead.
Meta asks an endpoint (a server address) for that data at each step. In Avox there are three ways to answer:
Every way sends every answer back to Avox when the Flow ends, so it shows in the Flow's Responses and the Inbox like any other Flow.
Nothing to host, no keys, no code. You turn on live data for a Flow, connect each screen to a table, and publish.
Turn on live data
In the Flow wizard, open Live data (next to Errors and Actions) and turn on This Flow uses live data. Avox endpoint (recommended) is picked for you. The panel shows whether your WhatsApp number is connected, whether Meta can reach Avox, and this month's live requests on your plan.
Connect a table to each screen that needs one
Under Screens and tables, each screen has two places for steps: When it opens (fill the screen with rows or values) and When it's submitted (check, save or book, then go on). Click Connect a table, pick a table (or make one from a premade table right there), pick what it does, and click Try it to see what your real rows give.
Let Avox add the live parts
A live Flow's JSON needs a few extra parts. When the checks under the steps say so, click Add live parts: Avox declares the data each screen gets (with examples from your real rows), turns the buttons that need data into ones that ask Avox, writes the routing, and makes sure every answer is sent along. The phone preview now answers from your real rows.
Publish
Click Create & publish. Avox makes your number's key, registers it with Meta, points the Flow at Avox's endpoint and publishes. Meta checks the endpoint before it publishes; Avox answers that check for you.
Start from a premade live Flow (the Live: read and save your tables group in the wizard). Each one says which tables it needs: pick yours, or click Make it now to make them from Avox's premade tables with example rows, and the Flow works straight away.
Columns are kept by their id, so renaming a column or a table never breaks a Flow. Changing a table's rows changes what customers see straight away; no publishing needed.
Customers never see an error page. Each step says what happens when nothing matches, a slot is full or none are left: ask again with a message (Avox's or yours), carry on, or go to another screen. When a table changes under a Flow (a column it uses is deleted, the table is archived), the Flow shows a friendly "please try again" on that screen, the Flow's page marks the screen in red (AVX-3526) and the table's Used by tab lists it.
Booking uses a table with a places column (how many people a slot or event takes) and a booked column (how many are taken). The premade Time slots and Events and seats tables have both.
A Flow whose last screen uses complete instead of asking Avox still confirms its holds when the
answers arrive.
With live data on, the preview in the wizard asks Avox exactly like Meta would, with your real rows: lists fill in, lookups show real values, and a full slot or a wrong pincode shows the message the customer would see. Nothing is saved, held or counted while you try it.
When a Flow's first screen loads table data, Meta must ask Avox before it opens, so the Flow is sent
with flow_action: "data_exchange". Avox's automations do this for you. If you send Flows through the
Avox API, do the same and leave out flow_action_payload. The premade live Flows never need it:
their first screen only asks a question.
Each screen of a live Flow that asks Avox is one live request. Plans include a number per Switchboard per month (Meta's health checks don't count). When they're used up, live Flows ask customers to try again later, the Flow's page shows AVX-3540, and the Switchboard's owner is emailed once that month. Avox also answers at most 600 live requests a minute per Switchboard and 60 per customer (AVX-3541).
The premade Appointment booking Flow uses two tables: Time slots (date, time, service, with, places, booked) and Appointments (where each booking is saved).
Riverside Salon
Book an appointment
Fill in the fields marked * to continue
Other premade live Flows: Event registration (seats, never oversold), Check order status, Browse products and check stock, Check delivery to a pincode, Check a coupon code (counts the use when it's applied), Get leads for a pre-approved loan, Provide insurance quote (premium from an Insurance rates table by age and cover), Capture interest for a personalised offer and Member sign-in or sign-up.
Meta locks every request with your WhatsApp number's public key; only the matching private key unlocks it. A number has one key at Meta.
When Meta's request can't be unlocked, the endpoint answers HTTP 421 and Meta fetches the public key again and retries. That's how a replaced key catches up.
A live Flow's page shows Live requests: how many requests it got, how many had a problem, the typical and the slowest answer times, problems by code, this month's live requests against your plan, and every request with each step's outcome (a table read, a slot held, a row saved) and how long it took. The log never holds the customer's answers, their phone number or the Flow's token: only the names of the answers sent. It's kept for 90 days.
On the same page, Live data shows where the data comes from and lets you change a screen's table links. Changes work straight away. A change that needs a screen to declare new data needs a new version of the Flow (Meta doesn't change a published Flow's JSON), which Avox publishes for you.
On a live Flow's page, Switch where its live data comes from picks Avox's endpoint (or pass-through, or your own server). While a Flow is still a draft at Meta, Avox changes its endpoint in place. A published Flow can't change its endpoint (AVX-3533), so Avox offers Publish a new version: the same screens, pointed at the new source, counting as one of your plan's Flows. Send the new version instead, then deprecate the old one.
Your own server decides what the customer sees, and Avox does the rest: Meta's encryption, keys,
time limits, retries, rate limits and the log. Pick Pass-through under Advanced: your own
server, enter your server's https:// address and click Make the secret. Copy the secret (it's
shown once) into your server's settings as AVOX_SIGNING_SECRET.
A POST with a JSON body, for every request Meta makes while the Flow is open:
{
"version": "2026-10-23",
"request_id": "flr_7hQ2kX9mVb1cN0pD",
"action": "data_exchange",
"screen": "QUOTE",
"data": { "age": "34", "cover": "10" },
"flow_token": "avx1.3c1f0a9e-1b2d-4c8e-9f00-2b6c1d7e8a91",
"flow": { "id": "6f1c...", "name": "Insurance quote" },
"answers": { "full_name": "Asha", "age": "34", "cover": "10" },
"contact": { "wa_id": "919876543210", "name": "Asha" }
}
action is INIT (the Flow opened and asks for its first screen), data_exchange (a screen was
submitted; data is that button's payload) or BACK (the customer went back to a screen that
refreshes).answers holds every answer given so far in this Flow message.X-Avox-Signature: t=<unix seconds>,n=<random>,v1=<signature> and X-Avox-Request-Id.The signature is the HMAC-SHA256, in hex, of <t>.<n>.<the raw body> with your secret. Refuse a
request whose t is more than 5 minutes off, and compare in constant time. For a day after you
replace the secret there are two v1 values (new and old): accept either.
Status 200 with JSON, within 5 seconds, at most 64 KB:
{ "screen": "RESULT", "data": { "premium": 7400 } }
{ "screen": "QUOTE", "data": {}, "error_message": "We can't quote that cover online." }
{ "close": { "policy_ref": "Q-1042" } }
screen must be a screen of the Flow; data must be what that screen declares (Avox fills in
anything it declares that you leave out, and drops anything it doesn't).close finishes the Flow; its values come back to Avox with every answer.The wizard has a ready snippet for Next.js and Express that checks the signature; your logic goes in
its answer function.
Your own server, with Meta calling it directly.
Direct needs a developer and replaces Avox's key for the number. Avox doesn't see the requests, so there's no request log and no tables; only the answers that come back.
Pick Direct under Advanced: your own server. The checklist there walks through it:
Your server's address
https:// address your server answers at.A key pair
Make a key pair makes it in your browser. The private key is shown once (copy or download it
into your server's settings as FLOW_PRIVATE_KEY); Avox never sees it. Register the public key
with Meta replaces Avox's key for the number, after you confirm.
Check it answers
A plain reachability check from Avox. Meta's own encrypted check happens when you publish.
The snippet
Put the snippet on your server. It unlocks Meta's requests (RSA-OAEP with SHA-256, then
AES-128-GCM), answers Meta's ping, and locks your answer with the request's key and the IV with
every bit flipped. Your per-screen logic goes where it's marked. It answers HTTP 421 when it
can't unlock a request.
Put every answer in params when you close the Flow: only those come back to Avox. Meta waits at
most 10 seconds for an answer.
Every live code is listed on Error codes.
Last updated