Your whole account runs on a single WABridges API key. Provision a bridge per tenant, tag each one with the customer it belongs to, and operate the fleet from one control plane, no per-tenant accounts, no spreadsheet of secrets.
The hard part of multi-tenant WhatsApp isn't the first number: it's the thousandth. Once you're past a handful of bridges, the questions get operational: which tenant owns which bridge, which ones are paired, which are silently disconnected, and which you're still paying for after a customer left.
WABridges is built to fan out from a single API key. One key authenticates every call; every bridge carries a customer_ref you control. That means your fleet's source of truth is your own database, not a pile of per-tenant credentials. Provision with one POST, list the whole fleet with one GET, and reconcile state on a schedule. We bill you a flat $5/month per active bridge, the rest of the operational discipline is a few patterns you set up once.
We keep the number online and hand you every event. You write the part in the middle.
You hold a single WA_API_KEY for your entire account. Every provisioning, send, and delete call uses it. There are no per-tenant logins or secrets to rotate, your tenant table is the only place ownership lives.
POST to /api/instances with customer_ref set to your internal tenant id (e.g. "cust_8842"). The bridge that comes back belongs to that tenant forever. Store its id on the tenant row so you can find it again without a lookup table.
GET /api/instances returns every bridge with its status and customer_ref. Run a periodic job that compares the live fleet against your tenant table, flag bridges with no tenant, tenants with no bridge, and anything stuck disconnected.
Group the fleet by status: paired and healthy, awaiting QR scan, disconnected, or orphaned. Re-pair the stuck ones, nudge the un-scanned ones, and delete the orphans so you stop paying for bridges no tenant owns.
Every loop below is the one above with your own logic in the middle.
Copy this prompt, paste it into any AI assistant, get working code in your language.
I run a multi-tenant product on WABridges. One API key authenticates my whole account, and each of my customers gets their own WhatsApp bridge, tagged with a customer_ref that matches my internal tenant id. My stack: [Node.js / Express + Postgres, update this to yours] My setup: - WA_API_KEY: my WABridges API key (one key for the whole account) - A "tenants" table; I want a "bridge_id" and "bridge_status" column on it I need three things: 1. provisionBridge(tenantId): POST /api/instances with customer_ref set to the tenant id and webhook_url pointing at my backend. Store the returned bridge id and status on the tenant row. 2. reconcileFleet(): GET /api/instances to fetch every bridge, then diff it against my tenants table. Return three lists: orphaned bridges (no matching tenant), tenants missing a bridge, and bridges whose status drifted from what I have stored. Update bridge_status from the live data. 3. A summary I can log on a cron: counts by status (paired, awaiting scan, disconnected) and the total monthly cost at $5/bridge. Please read the WABridges API docs before writing any code: https://wabridges.com/llms-full.txt Treat my Postgres tenants table as the source of truth for ownership. Make reconcileFleet() safe to run repeatedly: it should never delete anything on its own, only report drift so I can act on it.
What you get on the WhatsApp side, whatever you build on yours.
Other guides that build on the loop you just read.
Choosing a provider? See how WABridges compares to Twilio, 360dialog, and other WhatsApp API providers.