Webhooks
IT / TechnicalThis page covers how Preb handles webhooks. The short version: Preb receives webhooks from a few integrations (most notably Stripe), but it does not send outbound event webhooks to a URL you provide.
Available webhooks
There is no outbound webhook subscription
Preb does not offer a "subscribe to booking.created" style outbound webhook —
there is no webhook-endpoint configuration, no signing secret to verify
deliveries, and no delivery/retry queue. If you need to react to Preb events,
use one of the supported paths below instead.
To react to Preb activity, you have two options:
- In the browser, when a booking completes — use the embed's
window.Preb.on("bookingSuccessful", …)event. See Embedding the widget → Styling notes. - On your server, to push revenue in — call the transactions endpoint from your billing system when a payment succeeds.
The one customer-facing webhook Preb receives is the per-workspace Stripe webhook, described next.
The Stripe webhook
If you connect Stripe with an API key (rather than the one-click OAuth flow), Preb gives you a per-workspace webhook URL to add in your own Stripe dashboard so that payment events flow into Preb:
https://app.preb.co/api/integrations/stripe/webhook/{webhookToken}
The exact URL (and its signing secret) is shown in Integrations → Stripe when
you set up the API-key connection. The {webhookToken} is a random,
unguessable value that routes events to your workspace. For the full setup walk-
through, see Stripe payments & revenue.
Verifying signatures
The Stripe webhook is verified by Preb, not by you: Stripe signs each event with your connection's signing secret, and Preb checks that signature before accepting the event. You don't write any verification code for this direction.
For the opposite direction — when your server calls Preb's transactions endpoint — you sign the request with your API key's HMAC. See API keys → Authentication for that scheme.
Retries & idempotency
- Inbound Stripe events: if Preb fails to process an event, it returns an error so Stripe retries delivery. Processing is idempotent — the same Stripe event is recorded only once, so retries are safe.
- Your transactions calls: send an
Idempotency-Keyheader so a retried request doesn't create a duplicate transaction. A replay returns the original result with"idempotentReplay": true. See the transactions endpoint.