Docs

Every endpoint, three you'll actually use.

Provision a bridge, send a message, receive a webhook. The rest of the API is there for when you need media, contacts, presence or profile.

Connect a bridge API reference →

The basics3 Running it for real3 The rest of the surface3 Your account3

Create an account to get an API key

The basics

3 pages

The loop everything else sits on: one bridge, one send, one webhook.

Connect a bridge Create a bridge, link a WhatsApp number to it, and confirm it is connected - the three calls that come before everything else. Read Send a message POST a body and a chat id to a connected bridge - plus how to address a person or a group, and how to make a retry safe. Read Receive a message Point a bridge at your URL and every inbound WhatsApp message arrives as JSON - the payload, the rules your endpoint must follow, and how to prove a delivery is really ours. Read

Running it for real

3 pages

What changes once real traffic is hitting it.

Build without a phone Every account has a free sandbox bridge that answers the real API and replies like a real contact - no number, no card, no container. Read Errors and retries One error shape, a handful of status codes, and the two headers that make a failed call safe to send again. Read Stay connected Links drop - phones die, WhatsApp logs devices out. What the bridge tells you, which drops heal themselves, and which need a person. Read

The rest of the surface

3 pages

Media, groups, calls, presence and profile.

Send and receive media Images, video, audio, documents and stickers - sent by URL, received as a message id you download. Read Groups and contacts Read who is in a group, look up a contact, and check whether a phone number is on WhatsApp before you message it. Read Typing, presence and receipts The small signals that make a bot feel like a person: typing indicators, online state, read receipts, and knowing when the other side is typing. Read

Your account

3 pages

Keys, many bridges on one subscription, and what billing does.

Many bridges, one account One API key can run a WhatsApp number per customer - how to name them, address them, and what billing does as they come and go. Read API keys How keys are issued, what we can and cannot recover for you, and how to rotate one without downtime. Read What a bridge costs and when Running, paused, suspended - what each state means for your traffic and your bill, and what happens to an idle bridge. Read

The whole surface

One bearer key, one base path per bridge. These are the calls an agent actually makes.

Authorization: Bearer sk_…

POST/api/instancescreate a bridge
POST/api/instances/{ref}/proxy/pairlink a phone
POST/api/instances/{ref}/proxy/send/textreply
GET/api/instances/{ref}/proxy/statusconnected?
INhttps://your-app.com/hookevery event

Also here: quickstarts in seven languages, the whole reference as llms-full.txt for an assistant, and the OpenAPI spec for Postman or codegen.

Building with an AI agent?

One prompt for Claude, Cursor or ChatGPT: these docs, the base URL and the conventions that trip agents up the first time. Your key is never included.

I am integrating WABridges, a hosted WhatsApp REST API. Read the docs before writing any code:
- Full reference (Markdown): https://wabridges.com/llms-full.txt
- OpenAPI spec: https://wabridges.com/openapi.yml

My setup:
- Base URL: https://wabridges.com
- Each bridge has a customer_ref that goes in the API path. "default" always means the first bridge on the account.
- My API key is in the environment variable WA_API_KEY. Read it from the env; never ask me to paste it.

How the API works:
- Every bridge call goes to https://wabridges.com/api/instances/default/proxy/<path>, e.g. POST .../proxy/send/text with {"chat": "15550001234", "body": "hello"}.
- Auth: Authorization: Bearer $WA_API_KEY
- Phone numbers are E.164 digits with no "+".
- Errors are JSON {"error": "...", "code": "..."}. Branch on code, not on the message.
- An idle bridge answers its first call with 503 bridge_starting and a Retry-After header: wait, then retry.
- POST /api/instances returns 402 no_subscription until a phone number is connected in the dashboard. A subscription cannot be started from the API.
- Webhooks: verify X-Webhook-Signature "t=<unix>,v1=<hex>" where v1 is HMAC-SHA256 over "<t>.<raw body>" keyed with the bridge's webhook_secret. Dedupe on X-Webhook-Event-Id. Respond 200 right away and do the work afterwards.
- Rate limit: 120 requests per minute per key. Trial: 7 days.

The sandbox: every account has a built-in bridge at customer_ref "sandbox". It needs no phone and is never billed. It answers /status and the messaging endpoints with production-shaped responses; anything else returns 501 not_available_in_sandbox. It ignores Idempotency-Key and never posts to a webhook. Its one contact is 15550001234 (Alice), who replies a few seconds after every message. Build against it first.

First ask me two things: my language and framework, and what the integration should do. Then write it. Plain HTTP, no SDK.