Build without a phone

What the sandbox is

From the moment you sign up there is a bridge at customer_ref sandbox. It is not a container and not a WhatsApp connection - it is a simulation that answers the same REST surface with responses shaped like the real ones.

It costs nothing, needs no card, and does not count against your bridge limit. Use it to get your request signatures, error handling and message shapes right before a real number is involved.

curl

curl -X POST https://wabridges.com/api/instances/sandbox/proxy/send/text \
  -H "Authorization: Bearer $WA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"chat": "15550001234", "body": "hello"}'

A contact writes back

There is one simulated contact, Alice, on 15550001234 - the same number used throughout these docs. Send her a message and she starts typing, then replies about 4 seconds later. The reply is a real event with a real payload shape, so you can build against inbound traffic without owning two phones.

Messages to any other number come back as an error: Alice is the only chat that exists.

The sandbox accepts 60 sends per minute and keeps 7 days of events. Both are lower than production on purpose - it is a scratchpad, not a staging environment.

The one thing it does not do

Sandbox events are never delivered to a URL. They land in the dashboard, which streams them live, and that is where you read them.

So the sandbox exercises everything you send and every response you parse, but it does not exercise your webhook handler - not the endpoint, not the signature check, not your 2xx-fast discipline. That half is tested against a real bridge. Plan for it rather than being surprised by it on launch day.

If your integration answers every message automatically, you and Alice will ping-pong forever - she answers everything too. After a short burst she says so once and goes quiet for a minute. It is a deliberate mirror of a loop you can build in production, so treat it as a warning about replying to every event rather than a sandbox quirk.

When an endpoint says no

The messaging endpoints are simulated. Anything needing a live WhatsApp session - pairing, profile, presence, contacts - answers with a clear error instead of pretending.

Treat that response as a checklist: each one marks a code path that only a paired number will exercise.

← 400

{
  "error": "not_available_in_sandbox",
  "message": "This endpoint isn't simulated. Connect a real WhatsApp number to use it.",
  "docs_url": "https://wabridges.com/docs/api"
}

Moving to a real bridge

Nothing to migrate. Create a bridge with your own customer_ref, pair a number, and point your code at the new ref - see connect a bridge. Same key, same paths, same payloads.