Many hotels employ technology partners to send welcome emails once the guest has checked-in, or assess a guest's experience once the guest has checked out. To do this, the technology partner needs to retrieve the guest's contact information from the PMS database and be notified when a booking status has changed.
The Impala Stay makes this quick and easy to implement. There are several ways to do this, whether you wish to cache or not. We've outlined the most straightforward way, using guest profiles and webhooks for booking changes.
Configuring the webhook for changes in bookings
First, configure the webhook with the URL you want to call when changes are detected for that webhook.
As we're working with changes in the booking status, we want to configure the webhook for changes in the bookings. To do this, log into the Impala Management Console, go under "Webhooks" and configure the webhook for Booking Changed as per the screenshot below:
Once the guest has checked-out, the hotel will update the booking status from "CHECKED_IN" to "CHECKED_OUT". This will trigger a call to the URL for the webhook "Booking Changes". The same applies to sending welcome emails by inspecting changes in status from "EXPECTED" to "CHECKED_IN".
The payload will show the oldBooking, indicating the previous booking information, and the newBooking, indicating the new booking information. You will want to reference the "status" of the booking.
The payload appears as the following:
(Please note: we've removed some fields from the response to make it clearer)
{
"type": "BOOKING_CHANGED",
"hotelId": "56da6efe-3566-452d-a0a2-a82390d2fd72",
"version": "2018-11-27",
"events": [
{
"oldBooking": {
"id": "5dd2b488bb841dc97dc2c3a8",
"reference": "B-9M5214F",
"bookingSetId": "5dd2b48880a1d9aafee30d9b",
"status": "CHECKED_IN",
"start": 1576767600,
"end": 1576843200,
"areaId": "5dd2b4888daeb257f865b9d1",
"requestedAreaTypeId": "5dd2b488f54b92a79cd323ec",
"adultCount": 1,
"childCount": 2,
"infantCount": null,
"contact": {
"id": "5dd2b4882c22dbedf3fb1677",
"type": "guest"
},
"ratePlanId": "5dd2b488472b294ed502b7e3",
"guestIds": [
"5dd2b4882c22dbedf3fb1677"
],
"createdAt": 1574089866,
"updatedAt": 1576681447,
},
"newBooking": {
"id": "5dd2b488bb841dc97dc2c3a8",
"reference": "B-9M5214F",
"bookingSetId": "5dd2b48880a1d9aafee30d9b",
"status": "CHECKED_OUT",
"start": 1576767600,
"end": 1576843200,
"areaId": "5dd2b4888daeb257f865b9d1",
"requestedAreaTypeId": "5dd2b488f54b92a79cd323ec",
"adultCount": 1,
"childCount": 2,
"infantCount": null,
"contact": {
"id": "5dd2b4882c22dbedf3fb1677",
"type": "guest"
},
"ratePlanId": "5dd2b488472b294ed502b7e3",
"guestIds": [
"5dd2b4882c22dbedf3fb1677"
],
"createdAt": 1574089866,
"updatedAt": 1576758183,
}
}
]
}
Now that we know which guest has checked out using the guest ID 5dd2b4882c22dbedf3fb1677 we can find that guest's contact information using the GET /guest endpoint and the guest ID:
By reviewing the output, we see the guest's contact information and can now send a post-stay survey.
{
"data": {
"id": "5dd2b4882c22dbedf3fb1677",
"title": "Dr.",
"firstName": "Haley",
"middleName": "Sheridan",
"lastName": "Ruecker",
"sexCode": 1,
"emails": [
"Enid91@gmail.com"
],
"phoneNumbers": [
"632-168-1380"
],
"languageCode": "nor",
"nationalityCode": "URY",
"dateOfBirth": null,
"placeOfBirth": null,
"loyaltyPrograms": [],
"notes": null,
"classifications": [],
"addresses": [
{
"line1": "1169 Hannah Stream",
"line2": null,
"city": "Elijahton",
"postalCode": "16061-6904",
"countryCode": null,
"_extras": {
"state": "Tennessee"
}
}
],
"documents": [],
"createdAt": 1574089867,
"updatedAt": 1574089867,
"optIns": {
"marketResearch": false,
"thirdParty": true,
"marketing": false,
"misc": true
},
"contactBy": {
"email": true,
"sms": false,
"phone": true
},
"_extras": {},
"_meta": {
"lastRefreshedAt": 1574089900
}
},
"_meta": {
"pms": "IMPALA_PMS"
}
}
Alternatively, if you wish to reduce the number of API calls, you can retrieve all guest profiles using the GET /guest endpoint once or multiple times a day, and then cache these guest profiles.
In this case, once the URL is called for a booking status change, you can reference the cached data and avoid making a single API call to retrieve the specific guest profile using the guest ID.