This overview illustrates the work flow of the API calls from trivago to the advertiser's Express Booking implementation. In this documentation, the following URL will be used as the corresponding example endpoint of an advertiser's API implementation:
The trivago Express Booking API supports up to six API methods. To launch with trivago Express Booking only three API methods have to be implemented
|Checks booking availability||true|
|Validates availability of rate selected by the user||false|
|Submits a booking for a room||true|
|Authorises a booking if 3DS is required or PayPal is used||false|
|Verifies the status of the booking||false|
Hotel deals displayed on trivago are still based on hotel availability requests which can be made at any time and the results are cached for a period of time. So for the trivago Express Integration, no changes to the hotel availability requests have to be made. For using the trivago Express Booking funnel only "booking_availability" and "booking_submit" methods have to be implemented.
API calls are triggered by user interaction on the trivago Express Booking pages. The diagram below illustrates the user interaction possible:
Currently, the trivago Express Booking API work flow comprises two major phases, availability check and booking submission. In the first phase, the availability of the rate chosen by the users is verified. Therefor, a "booking_availability" (1.1) request is sent out to the advertiser once the user gets redirected to the trivago Express Booking landing page. This API call is made to ensure that only bookable rates are selectable on the landing page since the price displayed on the platform could have already been expired due to caching. If no rate is available or the user would like to search for rates for different dates or room occupancies, the user can update the search criteria on the trivago Express Booking landing page. In this case another "booking_availability" request (1.2) containing the updated search criteria is sent to the advertiser's API.
The availability results received in the "booking_availability" response are displayed to the user on the trivago Express Booking landing page. Following this, the user is able to select one of the available rate. Once a rate has been chosen, the user gets redirected to the trivago Express Booking checkout page, where customer name, address and payment information can be submitted. If the user remains for a longer period of time on the landing page another "booking_availability" request (1.3) is sent to the advertiser before the checkout page is loaded to ensure that in the meanwhile the chosen rate is still available. Besides that, trivago can optionally send out a "booking_prepare" request whenever the user gets redirected to the trivago Express Booking checkout page. This request is recommended to use, if at 1.1 & 1.2 only cached rates can be provided.
The second phase encompasses all API calls to process the booking. To go live with trivago Express Booking only the "booking_submit" request (2) needs to be supported. The "booking_submit" request contains all information to process the booking. If 3DS payment or PayPal is supported a "booking_payment_authorise" informs the advertiser once a payment has been authorised successfully. Once a booking has been submitted, trivago immediately verifies the booking status by sending a "booking_verify" request (optional).