There are several identifier fields in our event API that are used to correlate all of the events by customer and into a logical GXRs. The type of event will dictate whether or not certain Ids are required optional, or not allowed for that particular event.
Although the Overview section of these docs give a quick summary of the Ids, this page will dictate the proper usage and what it means to the system.
| Entity | Usage |
|---|---|
| Event.ReservationId | Whenever a GXR event is published, it must contain a unique reservation id
(unique according to the publisher's system). This is how all events for the
same reservation are correlated. If the publishing system uses ids that can be
recycled on a certain time interval (like a PNR Locator), then it should be
combined with another value to fully qualify it, for example the booking date.
(example: ABC123:20170501) |
| Event.CustomerId | The preferred method of identifying customers in our system is to add and maintain them globally, using a unique identifier from the publishing system. If the customer updates an email, phone number, or address, it should be published at that time the change happened. This will allow bookings to simply reference that customer by their CustomerId without sending the customer data each time. However, we realize that this is not always possible, so you may provide the ReservationId along with, or instead of, the CustomerId, and send the customer events along with the GXR events at the time of booking. |
| CustomerBooking event | Sending reservation id along with the customer events will properly link the customer
to the reservation. But this only applies if you are sending the customer data with each
booking. When the customer data is being managed globally, you can simply link a traveler
as being part of the reservation by publishing the CustomerBooking event.
This is a data-less event that provides CustomerId and ReservationId to tie the traveler
or travelers to a reservation. It also provides the ability to remove a traveler from a
reservation (for example when a PNR is split), by sending the event with Action: "delete".
CustomerBooking events are required for reservations with multiple customers. If no globally
unique identifier is available for a customer on a multi-traveler reservation, we recommend
combining ReservationId and some other consistent data like a traveler number if the
travelers are ordered or a combination of first and last names. |