Skip to main content
iBubbl only delivers webhooks to public https:// URLs, so to receive them on your laptop you expose a local server through a tunnel. You then trigger real events from your own phone and watch each delivery attempt in the dashboard.
There is no “send test event” button or endpoint. The only events are real ones: a message to or from your line. This guide uses your own phone to create them. To test your signature code without any events, use the test vector.

1. Run a receiver on port 8000

Any server that verifies the signature, logs the body and returns 200 will do. The receiver in Receive messages listens on port 8000. Start it with an empty IBUBBL_WEBHOOK_SECRET for now; you’ll get the real secret in step 3.

2. Open a tunnel

Pick one. Each prints a public HTTPS URL that forwards to http://localhost:8000.
Leave the tunnel running. A quick tunnel gets a new URL every time it starts, and webhook subscriptions can’t be edited, so after a restart you create a new subscription (step 3) and revoke the old one (step 6).

3. Register the tunnel URL

Create a subscription for the tunnel’s URL plus your route’s path. Leave out event_types to receive every event while you test.
The response includes the subscription id and its signing secret (whsec_…), shown only this once. Restart your receiver with IBUBBL_WEBHOOK_SECRET set to that secret. A URL that doesn’t start with https:// returns 422 invalid_url. You can also add the endpoint in the dashboard under Settings → Webhooks → Add endpoint; it’s the same subscription either way.

4. Trigger events from your phone

  • Inbound: text your iBubbl line from your own phone. Your receiver gets message.inbound.
  • Outbound: send a message to your own phone with POST /v1/messages. You get message.queued, then message.sent, then message.delivered and message.read if your phone reports them. Reply to it to get another message.inbound.
  • Reactions and edits: tap back on, or edit, a message in that thread for message.reaction.added and message.edited.
The first delivery usually arrives within about 30 seconds of the event.
Don’t text STOP (or unsubscribe, cancel, end, quit, stopall) to test opt-outs. It opts your own number out for good: an opt-out can’t be undone from the API or the dashboard. See Suppression and opt-outs.
Test events are real events. Every active subscription on your account whose filter matches receives them, including production ones. If production has an auto-reply, your test texts will get one too.

5. Watch the deliveries

In the dashboard, open Settings → Webhooks. Recent deliveries lists every attempt to reach your endpoints, newest first, across all your subscriptions: What common codes mean while testing: A failed delivery is retried for about 37 minutes; see Retries and deduplication. Fix your receiver and the next retry gets through. A delivery that went dead isn’t resent.

6. Clean up

When you’re done, revoke the test subscription. Revoking also stops any retries still pending for it. If you don’t have its id, GET /v1/webhooks lists your subscriptions.
Then stop the tunnel. Its URL stops working, so a forgotten subscription would only fail; revoking keeps your delivery log clean.

Next

Retries and deduplication

What happens when your endpoint fails.

Webhook events

Every event type and its payload.