Webhook Event Reference

This article lists exactly which actions in BRM cause a webhook event to fire, for each event type. It's the companion to Webhooks Overview — start there for what webhooks are and how to set one up.

reservation.create

Fires once, exactly when a new reservation is created, regardless of channel:

• A booking made through the Customer Booking Portal (CBP)
• A booking made through the legacy Online Booking Widget (OBW)
• A reservation created in Back Office or via the API

reservation.update

Fires once per action, after the change is saved. The following all trigger it:

• Stage & status changes — confirming a booking, checking in/out, and similar manual stage changes made in Back Office
• Items — adding an item, removing an item, or swapping one allocated item for another
• Extras (add-ons) — adding an extra or removing one — both directions fire this event
• Pricing & discounts — applying or removing a discount (code or manual), applying an approved repair-quote charge to a reservation
• Notes — adding, editing, or deleting a reservation-level note; adding or editing a per-item note
• Dates & times — changing the start or end date/time
• Delivery — adding, changing, or removing delivery address/details
• Payments — with an important caveat. This event fires when a payment is confirmed through Stripe (including the async confirmation Stripe sends back after checkout) or through PayPal. It does not fire when a staff member manually records a payment in Back Office (e.g. logging cash or a card taken outside BRM). If your integration needs to know about every payment regardless of how it was taken, don't rely solely on this event for that case.
• Public API (v1) — adding a note, a check-in/check-out transition, or a customer requesting cancellation, all made through the public booking API, also fire this event

Known gaps — things that do not currently fire a webhook:

• A provisional/unpaid reservation that gets automatically cancelled by the booking-hold timeout does not fire reservation.update (or any other event). If your integration needs to detect an expired hold, you currently need to infer it another way — for example, by tracking your own copy of the hold window. This is a known limitation we're tracking.
• Uploading or removing a document attached to a reservation doesn't fire anything.
• The public API's "update reservation contact info" endpoint updates the customer's saved details, but only fires reservation.update — it does not also fire a customer.update event for that specific change.

customer.create / customer.update

Fires when a customer record is created or updated:

• Through the standalone "create/edit customer" flow in Back Office or the API
• Automatically, as a side effect of an online (CBP) booking that creates a new customer or updates an existing one's details

customer.merged

A separate event from customer.update, fired when two duplicate customer records are merged into one. Its data object has a different, smaller shape than the other customer events — see Example of Customer JSON Data Sent via Webhook for the exact fields. Note that un-merging a customer does not have its own event — it re-fires customer.update for the records involved.

See also

Webhooks Overview
Setting Up Webhooks
Example of Customer JSON Data Sent via Webhook
Example of Reservation JSON Data Sent by Webhook