Link Search Menu Expand Document

Guest Update endpoint

Accepts a POST call and stores waiver details as seen fit. Wherewolf will call this endpoint to share a waiver signed by a guest, this allows your system to create or extend guest details and know when a waiver has been signed.

After a guest have signed a waiver, or after any other update is performed on a waiver record. Wherewolf will execute a POST call to a Guest Update endpoint on your booking system API.

NOTE: Waivers may have multiple steps where the participant may complete the waiver in multiple sessions.
In this case, the waiver will be updated with the latest information after each step and a new call will be made to the endpoint.

Parameters (on path or as query string):

  • bookingId the booking id
  • bookingGuestId the guest id provided originally with the booking details (if available)

Headers:

  • API-key API key to allow the request.

Body:

  • waiver.id the Wherewolf waiver id, will be unique across all waivers (you can use it to detect update calls). Be aware the waiver ID is a string with a max of 256 bytes, and it may contain non url safe characters.
  • waiver.pool is the ID used by Wherewolf to identify a Wherewolf app, your endpoint may use this to match the waiver to an account/client.
  • waiver.bookingId the booking id.
  • waiver.bookingGuestId the booking system’s guest id provided originally with the booking details (if available)
  • waiver.lastVisit the date and time of the activity/activities the guest is checking-in. UTC ISO 8601.
  • waiver.status is string. When set to “Deleted” it indicates the waiver has been voided and should be removed from the system. Any other value indicates the waiver is Active (and still relevant).
  • waiver.updatedAt the date and time of the last update stored for this record. UTC ISO 8601.

Note: Other properties may be available depending on use cases, check the “Other Properties” down on this page

Request example

This is an example, you may have another url structure

curl -X POST \
  __BOOKING_SYSTEM_API__/bookings/ABC123/guests/__URL_ENCODED_BOOKING_GUEST_ID_OR_WAIVER_ID__ \
  -H 'Content-Type: application/json' \
  -H 'API-key: 123-123-123-123' \ 
  -d '{
        "waiver": { 
            "id": "abcdefg-12:30-1234567890#1",
            "pool": "qwerty123",
            "bookingId": "ABC123",
            "bookingGuestId": "G333",
            "lastVisit": "2018-01-27T11:27:00.000Z",
            "status": "Checked In",
            "updatedAt": "2018-01-27T11:21:33.444Z"
        }
    }'

Where BOOKING_SYSTEM_API is a placeholder for the base url of your booking system’s API.

And URL_ENCODED_BOOKING_GUEST_ID_OR_WAIVER_ID is the guest id from YOUR system bookingGuestId if/when provided, optionally this can be filled with the Wherewolf waiver.id or left empty. URL encoded when present.

Response example

{
    "success": true
}

Other Standard Properties

Depending on the use case, the process of check-in may capture other details from the guest, such as “Date Of Birth” or “Where did you hear about us”.

When extra properties are available in the waiver, these could be included in the payload.

When setting up your integration, you will need to decide and define what “Other Properties” may be of use for your clients (if any).

By default, Wherewolf won’t send these unless deemed necessary for your use case and with express permission of your client in accordance to privacy regulation.

While custom fields may be different for each operator’s app, there are some frequent questions that when in use will store the answer in predefined property names. Property names of frequently used questions