Webhooks

A Wherewolf webhook sends guests or bookings to an endpoint of yours as they change. Customers add, change and pause their webhooks themselves in the Dashboard, under Settings › Webhooks, on plans that include webhooks. Setting one up, and checking each request and what the endpoint answered, is described in the help centre: Webhooks: sending guests and bookings to your own systems.

This page is for whoever builds the endpoint.

The request

A POST to the webhook’s URL, with a JSON body and Content-Type: application/json. Use an https URL.
Authentication: the webhook’s Auth Field and Auth Value are sent as a header, <Auth Field>: <Auth Value>, for example X-API-KEY: your-key. A webhook with no Auth Value sends no header. Some webhooks Wherewolf set up before the Dashboard managed them send Authorization: Basic <base64 of field:value> instead.
Only what the customer chose: each webhook sends the fields its whitelist names, plus the fields listed below as always sent.
Only changes made after the webhook is added are sent. Changes made within a few seconds of each other arrive as one request with the latest state, and a booking that the booking system sends again unchanged is not sent again.

Guest webhooks

Sent when a guest completes a waiver, and again whenever the guest changes: they check in on arrival, staff edit them, their status changes and so on.

{
  "guest": {
    "activities": ["harbourcruise"],
    "email": "alex@example.com",
    "lastVisit": "2026-11-04T21:00:00.000Z",
    "name": "Alex Example",
    "returnedToBase": "Still out",
    "id": "abc123_newGuest441298_1762034567890",
    "TMP_id": "abc123_newGuest441298_1762034567890",
    "deleted": false,
    "reservationsID": "385210441",
    "reservationsService": "fareharbor",
    "status": "Checked In"
  }
}

Always sent:

Field	Meaning
`id`	The guest’s ID. `TMP_id` repeats it for older integrations.
`status`	`Active`, `Checked In`, `Deleted`, `Finalised`, `Incomplete`, `Ineligible`, `No-Show` or `Blank`
`deleted`	`true` when `status` is `Deleted`
`reservationsID`	The booking the guest belongs to, as the booking system identifies it; absent for a walk-in
`reservationsService`	The App’s booking system, such as `fareharbor`, `rezdy` or `none`

Any other guest field can be chosen, the App’s custom fields among them, under each custom field’s property name (returnedToBase above). lastVisit is in UTC. A guest that skipped a question has no value for it.

Booking webhooks

Sent when a booking from the App’s booking system is created, updated or cancelled, for the events the webhook receives.

{
  "event": "updated",
  "changedFields": ["pax", "startTime"],
  "booking": {
    "customer": { "email": "alex@example.com", "name": "Alex Example", "phoneNumber": "+64 21 000 0000" },
    "pax": 3,
    "startTime": "2026-11-04T21:00:00.000Z",
    "waiverLink": "https://web.wherewolf.co.nz/xk4p2q",
    "id": "385210441",
    "pool": "abc123",
    "provider": "fareharbor",
    "status": "Active"
  }
}

Field	Meaning
`event`	`created`, `updated` or `cancelled`. A rebooking is `updated`, with `status` `Rebooked`.
`changedFields`	For `updated` only: the booking fields that changed
`booking.id`	The booking system’s ID for the booking; a guest’s `reservationsID` holds the same value
`booking.pool`	The Wherewolf App’s ID
`booking.provider`	The booking system
`booking.status`	`Active`, `Deleted` (cancelled), `Pending` or `Rebooked`

The booking fields a webhook can choose:

Field	Meaning
`activities`	The IDs of the booked activities
`activitiesAsObjects`	Each booked activity’s `id` and `name`
`bookedSessions`	Each booked session’s `activityId`, `activityName`, `startsAt` and `endsAt`
`bookingLabel`	A short summary, such as the customer’s name, the activity and the number of people
`customer`	`name`, and `email` and `phoneNumber` when the booking system has them
`displayId`	The booking number the booking system shows its customers
`endTime`, `startTime`	When the booking ends and starts, in UTC
`name`	The name the booking is under
`paid`	The payment status, in the booking system’s own words
`pax`	The number of people booked
`waiverLink`	The booking’s waiver link, as the pre-arrival email sends it; `null` for a cancelled booking. Anyone with it can open that booking’s waiver.

Booking webhooks carry no participants and no custom fields; custom fields belong to guests.

Answering

Return a successful final response, normally 200 OK. Wherewolf records the request as delivered only when the final answer is a 2xx, is not an HTML page, and its body does not say "success": false, "ok": false, or "status": "error" or "failed". Any other body, including an empty one, is fine. This confirms your endpoint’s acknowledgement; it does not prove that downstream work has finished.

Redirects

Wherewolf follows up to ten redirects and validates the final response using the same rules as a direct response. A redirect by itself does not confirm delivery.

Redirect	Request to the next URL
`301`, `302`, `303`	A `GET`, without the original POST body
`307`, `308`	The original method and JSON body

The configured authentication header is removed when a redirect changes origin (scheme, host or port). Keep authentication on the receiving endpoint; do not require that header on a receipt hosted at another origin.

Google Apps Script’s ContentService processes the POST and redirects to its response on script.googleusercontent.com. Configure the webhook with the deployed script’s /exec URL, rather than copying the temporary content URL. Return a plain-text or JSON acknowledgement, such as {"ok": true}, and make the deployment accessible without an interactive Google sign-in. Wherewolf follows the content redirect with a GET and checks the final response. Google documents this flow in its Content Service guide. A login page, an error page, a negative acknowledgement or a redirect loop cannot confirm delivery, even if a page returns HTTP 200.

Failures and retries

A direct 4xx answer (other than 408), or an address that cannot be resolved or refuses the connection, is recorded as Failed. Eligible definite rejections may be retried immediately up to three times, with later attempts about 5 minutes later and about 25 minutes after that, while the webhook remains enabled.
A 5xx, a timeout, an HTML page or a negative acknowledgement is recorded as Sent: sent, but not confirmed. Wherewolf does not automatically resend an uncertain POST, because your endpoint may already have processed it.
After any redirect, an unconfirmed final response stays Sent, even if the receipt returns a 4xx or cannot be reached. The original POST is not resent automatically. Check your service’s records before deciding whether the guest or booking needs to be sent again.

An x-request-id header on a successful answer is shown with the delivery in the Dashboard as its reference.

Every attempt’s request (URL, headers, body) and final answer (status, headers, final URL, redirect chain and up to 256 KB of the body) is saved, and the customer can open it from Discover › Automations in the Dashboard. The saved request includes the auth header.