WABridges
← All guides
Guide

Provision on signup.
Deprovision on churn.

Let your billing system run your WhatsApp fleet. Hook bridge creation to a new subscription and teardown to a cancellation, and every account gets a number the moment it's paid for — and gives it back the moment it isn't.

Manually creating and deleting WhatsApp bridges doesn't scale, and worse, it leaks money: every bridge someone forgets to delete keeps billing at $3/month for a customer who already left. The fix is to stop treating provisioning as a human task and wire it into the events that already define your customer lifecycle — the ones Stripe (or whatever bills you) is already firing.

With WA Bridges, the whole lifecycle is two API calls hung off two billing events. A subscription goes active → provision a bridge. A subscription cancels → delete it. Everything in between — pairing, messaging, status — runs itself. Make the handlers idempotent so a replayed webhook never double-provisions, and your fleet becomes self-managing: it grows exactly with your paying customers and shrinks exactly with your churn, with no manual step in the middle.

How it works

1
Provision when a subscription goes active
On the billing event that means "this customer is now paying" (e.g. Stripe customer.subscription.created or invoice.paid), POST to /api/instances with their customer_ref and store the returned bridge id on the account.
2
Make every handler idempotent
Billing webhooks get retried and replayed. Before provisioning, check whether the account already has a bridge; if it does, do nothing. One account should never end up with two bridges from a duplicate event.
3
Deprovision when they churn
On cancellation or final non-payment (e.g. customer.subscription.deleted), delete the bridge and clear the id from the account. Your $3 charge stops the same day, with a prorated refund for the unused time.
4
Reconcile so nothing leaks
Run a periodic sweep that compares live bridges against active subscriptions. Any bridge whose subscription is gone is a leak — delete it. Any active subscription with no bridge gets one. Billing and fleet stay in lockstep.

What you can build

🟢
Provision on signup
  • Trigger on subscription active
  • POST /api/instances with customer_ref
  • Store bridge id on the account
  • Customer is live the moment they pay
🔴
Deprovision on churn
  • Trigger on cancellation
  • Delete the bridge, clear the id
  • Cost stops the same day
  • Prorated refund for unused days
♻️
Idempotent handlers
  • Webhooks get replayed — assume it
  • Check for an existing bridge first
  • Never double-provision an account
  • Safe to retry, safe to re-fire
🧭
Lifecycle reconciliation
  • Sweep bridges vs active subs
  • Delete bridges with no subscription
  • Provision subs with no bridge
  • No orphaned $3 charges left behind

Paste into Claude, ChatGPT, or any AI assistant

Copy this prompt → paste into any AI assistant → get working code in your language.
I want my WhatsApp bridge fleet on WA Bridges to manage itself off my
Stripe billing events: provision a bridge when a customer starts paying,
delete it when they churn, so I never pay for an abandoned bridge.

My stack: [Node.js / Express + Stripe + Postgres — update this to yours]
My setup:
- WA_API_KEY: my WA Bridges API key
- Stripe webhooks already hitting my backend
- A "customers" table; each row has a stripe id I'll use as customer_ref
  and a place to store a bridge id

I need a Stripe webhook handler that:

1. On customer.subscription.created (or invoice.paid), provisions a bridge
   via POST /api/instances with the customer as customer_ref — but ONLY if
   that customer doesn't already have a bridge id stored. Make it
   idempotent against replayed events.

2. On customer.subscription.deleted, deletes the customer's bridge and
   clears the stored id so my $3 charge stops.

3. A standalone reconcile() function I can run on a cron: list all bridges,
   compare against active Stripe subscriptions, delete any bridge with no
   active subscription, and provision any active subscription missing one.

Please read the WA Bridges API docs before writing any code:
https://wabridges.com/docs.txt

Idempotency is critical — Stripe retries webhooks, and I must never
double-provision or orphan a bridge. Comment those guard checks clearly.

Why WA Bridges