WABridges
← All guides
Guide

One API key.
A fleet of WhatsApp numbers.

Your whole account runs on a single WA Bridges 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.

Start free → View API docs

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.

WA Bridges 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 $3/month per active bridge — the rest of the operational discipline is a few patterns you set up once.

How it works

1
One key authenticates the whole fleet
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.
2
Provision with a customer_ref you own
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.
3
Reconcile the fleet on a schedule
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.
4
Operate by status, not by guesswork
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.

What you can build

🗂️
Source of truth
  • customer_ref on every bridge
  • Bridge id stored on the tenant row
  • No per-tenant secrets to manage
  • Your DB owns ownership, not us
🔄
Fleet reconciliation
  • List all bridges in one GET
  • Diff live fleet vs tenant table
  • Flag orphans and missing bridges
  • Run it on a cron, alert on drift
🩺
Health at scale
  • Group by status across the fleet
  • Spot disconnected numbers fast
  • Re-pair before customers notice
  • Dashboards keyed by customer_ref
💸
Cost control
  • Flat $3/month per active bridge
  • Delete orphans to stop billing
  • Prorated refund on cancellation
  • No surprise per-message fees

Paste into Claude, ChatGPT, or any AI assistant

Copy this prompt → paste into any AI assistant → get working code in your language.
I run a multi-tenant product on WA Bridges. 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 WA Bridges 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 $3/bridge.

Please read the WA Bridges API docs before writing any code:
https://wabridges.com/docs.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.

Why WA Bridges