How to Use Webhooks with WaveRez

WaveRez can automatically send booking and waiver information to another system, like Zapier, Make, or your own CRM, whenever something important happens. This is done using a webhook, which lets two systems talk to each other automatically without anyone clicking a button.

A webhook sends WaveRez booking, waiver, crew, and cart data to another system automatically as events happen, without anyone clicking a button. You configure webhooks in WaveRez Admin, and you can send different events to different destinations by adding more than one endpoint URL.

Step 1 — Go to the Admin Area of WaveRez, then click Integrations, then click Webhooks. WaveRez Admin opens the Webhooks page and displays a description of the available events above the configuration panel.

Step 2 — Tick the Use Webhook checkbox. WaveRez enables webhook sending for your account. No data is sent until you also enter an endpoint URL.

Step 3 — Paste your destination address into the Webhook Endpoint field. This is the URL provided by Zapier, Make, your CRM, or your own server. WaveRez sends event data to whatever address you enter here.

Step 4 — Click the Trigger for dropdown next to that endpoint and tick the events you want this endpoint to receive. The available events are New Bookings, Updated Bookings, Cancelled Bookings, Waiver Completed, Crew Assignment Updated, and Cart Abandoned. Tick Select all to send every event to this endpoint. The dropdown displays a count of how many events you have selected, for example "6 selected."

Step 5 — Add more endpoints if you want different events going to different systems. Click Add new url, paste the second destination address into the new Webhook Endpoint field, and choose that endpoint's events in its own Trigger for dropdown. Each endpoint has an independent event selection, so you can send booking events to your CRM and waiver events to a marketing tool without sending everything to both. Click the red trash icon beside an endpoint to remove it.

Step 6 — Tick Include Dynamic Waiver URL if you want waiver links included in the data WaveRez sends. This option applies to WaveRez Waivers only. Trips that still use a Wherewolf waiver do not produce a waiver URL in the payload regardless of this setting.

Step 7 — Click Save. WaveRez saves your endpoints and event selections and begins sending data as those events occur. Send a test event from your destination system to confirm the connection before you build automations on it.

Every webhook includes a type field identifying what kind of record it is, and an event field identifying what happened to it. Check both before processing, because the shape of the data differs by type. Booking events put their data under a booking object, while waiver, crew, and cart events use a data object.

WaveRez sends six event types. In plain terms: three cover the life of a booking, one fires each time a guest signs a waiver, one fires as crew assignments move through assignment and response, and one fires when a customer leaves your booking portal without finishing.

The Crew Assignment Updated setting in the Trigger for dropdown is a single option that covers all three crew events. Ticking it sends assigned, accepted, and declined. There is no way to receive only one of the three.

Actions that do not change the underlying record do not trigger a webhook. Sending an SMS or email, or a declined payment attempt, produces no event.

A few things to understand before you build an automation:

Webhooks send the current state, not a list of changes. An updated event contains the booking as it exists right now. It does not tell you which fields changed. If you need to detect what changed, store the previous version on your side and compare.

Rapid changes are batched. If a booking is edited several times in quick succession, you'll typically receive one webhook reflecting the final state rather than one per edit. This keeps your integration from being flooded, but it means the webhook is a snapshot, not an audit trail.

A booking contains one or more cart_items — each one is a trip on a specific date and time.

Options selected by the customer appear twice in a booking payload. The additional_options array on each cart item holds them in structured form, with the option's question in name and the customer's selection inside the value object. The same selections are also appended to the human-readable booked_format string, which for a booking with two options reads something like 1 x $100.00 1 Hour Rental + No, thanks. ($0) + Born On or After January 1st, 1988 ($0). Use additional_options when you need to act on a specific selection, and booked_format when you just need a readable summary for a CRM note or a message to staff.

calendar_id identifies a specific departure slot, and every booking on that same departure shares the same value. It is not unique to a booking, and it changes if a booking is moved to a different date or time.

An updated event looks identical, with "event": "updated", "new": false, and the changed values in place.

When the Include Dynamic Waiver URL checkbox is ticked under Integrations > Webhooks, WaveRez adds a waiverURL field to every booking webhook payload. The waiverURL is the customer-facing link that lets guests on that order complete their waiver, the same link customers receive by email and SMS and the same link staff see in the Signed in Guests section of the order Overview.

The waiverURL sits at the top level of the booking object alongside detailsURL and access_link, not inside cart_items. There is one waiver URL per order, not one per trip. If an order contains several trips that use different waivers, the single waiverURL still covers the whole order, and the page it opens presents each required waiver to the guest.

A waiverURL value looks like https://waivers.waverez.com/order/b0b8bc1fb379f4c4-rhbm.

This is the field that makes waiver reminder automations possible. Send the waiverURL to a Zapier or Make scenario alongside customer_email and start_at, and you can text or email guests who have not signed as their trip date approaches.

A cancellation arrives as "event": "cancelled" with "cancelled": true, "state": "cancelled" at both the booking and cart-item level, and a cancel_reason on the affected cart item.

Monetary totals are zeroed on a cancelled booking. subtotal, net_total, subtotal_tax, subtotal_fee, and surcharges will all read 0.

If you need the original value of a cancelled booking for reporting, you have two options:

Trimmed for readability — the full payload carries the same fields as a created event.

This is new. When a guest completes a waiver, WaveRez sends that guest's information to your webhook. Previously you only received data for the lead booker; now you receive a separate webhook for every guest who signs.

This is what makes it possible to:

Waiver payloads use "type": "Waiver" and put everything under a data object — not booking. Branch on type first in your automation.

In plain terms, a waiver webhook gives you one guest's identity and contact details, their marketing consent choices, which waiver they signed, and an audit trail of the signature itself. The fillId is unique per signer and is the value to deduplicate on. The firstName, lastName, email, and phoneNumber fields hold that individual guest's details rather than the lead booker's. The getEmailPromotions and getPhonePromotions fields hold that guest's marketing consent as the string "1" for opted in or "0" for not. The birthDate field is formatted MM/DD/YYYY. The driverLicenseNumber field appears only when the guest indicated they are driving and your waiver collects that number, and it is sensitive personal data. The waiverTitle and waiverId fields identify which waiver was signed, completed reads "1" when the waiver is finished, and signatureMetadata is an object holding the full signing audit trail. Any field with a field_ prefix is a custom question you added to your own waiver, and those keys are generated per waiver so they differ between waivers.

The example above shows three custom fields, field_DaAJ, field_4i-t__ack-1, and field_4i-t__bszj. The number of custom fields and the exact key names depend entirely on how you built your own waiver, so do not hard-code these keys in an automation. Read them dynamically or map them once against a test payload from your own waiver.

Every waiver webhook includes a signatureMetadata object recording the circumstances under which the guest signed. This is the closest thing WaveRez sends to an audit trail for a signature, and it is the part of the payload that matters if a guest later disputes that they signed or claims someone else signed for them.

The signedAt value is the exact moment the guest completed the waiver, given in UTC with millisecond precision, for example 2026-07-24T18:40:06.400Z. Convert from UTC when comparing against times shown elsewhere in WaveRez.

The timezone value is the guest's own device time zone, such as America/Chicago, which is not necessarily your business's time zone.

The device value is a short human-readable summary such as macOS Chrome. The platform value is the operating system on its own, such as macOS.

The userAgent value is the full raw browser user agent string. The userAgentData object breaks the same information into structured parts: a brands array listing the browser engines and their versions, a mobile value of "1" when the guest signed on a mobile device or "0" when they did not, and a platform value repeating the operating system.

If you store waiver data in a CRM or spreadsheet, signedAt and device are the two values worth keeping. The full userAgent string is verbose and rarely useful on its own, but preserving it costs nothing and it is the value that carries the most weight in a dispute.

Waiver payloads carry the IDs you need to match a signed waiver back to the booking it belongs to:

Three things to keep in mind:

Deduplicate on fillId, not email. Guests frequently enter the lead booker's email address for the whole party, and some enter nothing meaningful at all. fillId is the only value guaranteed unique per signer.

For trip date and time, always read the booking — not the waiver. The waiver's arrivalAt reflects the trip date at the moment it was signed. If the booking is later rescheduled, the waiver record is not resent and its date will be out of date. Join on orderId and take the date from the booking's start_at.

There is no "everyone has signed" event. Each waiver arrives on its own, and minors typically don't sign, so ticket counts won't reliably tell you how many waivers to expect. Treat each waiver as an independent record.

Crew webhooks fire as a crew assignment moves through its lifecycle. A crew member is a WaveRez user whose Type is set to Crew member under General > System setup > Users. When you assign that person to a trip, they receive an email notification and can accept or decline it. Each of those three moments sends a webhook.

Crew payloads use "type": "Crew" and place everything under a data object, not booking. The event field is assigned, accepted, or declined.

The data.crew array contains the crew member's firstName, lastName, email, phone, and status. The status value mirrors the event value, so an accepted event carries "status": "accepted". The phone field is empty when the crew member has no phone number saved on their user record.

The data.trip object contains the trip's name, the equipmentName of the boat or unit assigned, the scheduleTime and endTime as clock times, and the duration in minutes.

Example: crew assignment sent

A few conventions worth knowing before you build:

Dates come in several formats. Use start_at and end_at when you need a precise, time zone-aware moment. arrival_date is date-only. arrivalAt on a waiver has no time zone attached. signedAt is UTC. birthDate is MM/DD/YYYY.

Many yes/no values are sent as text. You'll see "0" and "1" as strings alongside true JSON booleans like is_direct: true. Zapier and Make treat "0" as a non-empty text value, so test your filters — a check for "is true" won't behave the way you expect on these fields.

Use booking.id and cart_items[].id as your keys. They're permanent. calendar_id, schedule.id, and format_id can all change or repeat.

Waiver payloads can contain sensitive personal information, depending on how you configured your waiver. Depending on your form, a single payload may include the guest's full name, date of birth, home address and ZIP code, gender, email address, phone number, emergency contact name, phone, address, and ZIP code, their answer to any medical or health question you added, their driver's license number in the driverLicenseNumber field, and the full browser user agent string and device time zone in the signatureMetadata object.

That data is sent to whatever URL you enter, and it will be stored by whatever service receives it, including in that service's task and run histories.

Before you turn on waiver webhooks:

If you're unsure whether your setup is appropriate for the data you collect, reach out to WaveRez support before enabling waiver webhooks.