WABridges
How it works

Three calls, one webhook.

A bridge is one WhatsApp number, connected as a linked device, with a REST API in front of it and a webhook behind it. We keep the session online. You write the code that decides what to say.

Architecture

Your app talks REST to the bridge. The bridge talks WhatsApp. Everything inbound comes back to your webhook URL.

You run
Your app
any language,
any model
POST /send/textwebhook POST
We run
Bridge
session, REST,
webhooks
WA protocolinbound event
They use
WhatsApp
a real number,
any phone
Outbound: your REST callsInbound: webhooks to your URL

One number. One hosted session.

Every WhatsApp number you connect gets its own bridge. Think of it as the phone that stays logged in, except it lives on our servers and answers to HTTP.

One number per bridgePair any WhatsApp number, personal or business. Need ten numbers? Run ten bridges.
A linked device, not the Business APISame multi-device protocol as WhatsApp Web. No Meta approval, no templates, no 24-hour window.
Addressed by your customer_refYou pick the ID when you create it. Every later call and every webhook carries it.
The session survives restartsPair once. If WhatsApp drops it, your webhook hears about it and a re-scan brings the same bridge back.

Provision. Pair. Send. Listen.

Every call takes your account API key as Authorization: Bearer sk_…. One is created at signup; make more from the dashboard.

1
Provision a bridge
One call, running immediately

POST with a customer_ref you control (a user ID, an order number, any string) and the webhook URL that should receive events. The ref you choose addresses the bridge in every later call.

Provisioning over the API adds bridges to an existing subscription. Create the first bridge from the dashboard (one click, 7-day free trial with a card on file); everything below works the same either way.

POST /api/instances
{
  "customer_ref": "user-123",
  "webhook_url": "https://your-app.com/hook"
}

← {
  "id": "7d09aa9c-…",
  "customer_ref": "user-123",
  "state": "running"
}
2
Pair a phone number
Scan a QR, or request a link code

Scan the QR in the dashboard, or call /proxy/pair to get an 8-character code. In WhatsApp: Linked devices › Link a device › Link with phone number. Once paired, GET /proxy/status returns "status": "connected" with the number and display name.

Link a deviceAny number works, personal or business. The session persists across restarts.0:58 to live
POST …/user-123/proxy/pair
{ "phone": "15550001234" }

← { "code": "ABCD-EFGH" }
3
Send a message
Digits only, no plus sign

POST to /proxy/send/text with the destination number and the body. You get back a message ID and a Unix timestamp. The same proxy sends media, polls, reactions, locations and more; the API reference lists every endpoint.

POST …/user-123/proxy/send/text
{
  "chat": "15559876543",
  "body": "Hello from my app!"
}

← {
  "message_id": "ACE41E...",
  "timestamp": 1777180605
}
Listen for events
No polling, ever

Every inbound message, delivery receipt, call and status change is POSTed to your webhook URL as it happens. Reply with 200 OK to acknowledge. Put your model behind this handler and you have an agent. Every event type is in the API reference.

webhook → https://your-app.com/hook
{
  "type": "message",
  "from": "15559876543",
  "body": "Hey, got your message!",
  "timestamp": 1777180621,
  "message_id": "BD71F2...",
  "customer_ref": "user-123"
}
WhatsApp drops the sessiont = 0
Your webhook gets disconnectedinstantly
The dashboard shows the QR againre-scan
Same bridge, key and webhooks are back~1 min

Nothing to rebuild. Re-scan and go.

Sessions can drop: a phone wiped, a number moved, WhatsApp logging out a linked device. Your app finds out from us, not from your users.

While a bridge is down, sends return an error instead of silently dropping, and inbound messages still land on the phone as normal because the bridge is just a linked device.

Worried about bans? The honest answer is on the pricing page →

Your first message. Any language.

Send with any HTTP client. Replace CUSTOMER_REF with the ref from step 1 and API_KEY with the key from your dashboard.

bash
curl -X POST \
  https://wabridges.com/api/instances/$CUSTOMER_REF/proxy/send/text \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"chat":"15559876543","body":"Hello!"}'

Want the full tutorial with webhook handling? See the step-by-step quickstarts: Node.js, Python, PHP, Ruby, Go, Rust, Java.