Your EPS account

Reset your password

Please enter your email address below. We will send password reset instructions to the email associated with your EPS account.

Back to sign in

Handling Booking Requests

It is important to handle booking requests properly in order to avoid errors and losses.

Overview

It is important to design your booking request workflow to be tolerant of network issues. Do not interpret a lack of a response as an indicator of a failed booking. If an infrastructure issue occurs after a reservation request is sent but before the response is received, then your customer's booking may still have been charged & confirmed within EPS's systems. The infrastructure issue could be:

The network connection is lost (for example, no response returned)
Server-side error is returned (for example, HTTP Code 500, 503 is returned)
A bad network gateway is observed (for example, HTTP Code 502 is returned)
Network gateway timeout is observed (for example, HTTP Code 504 is returned)
A response is not following the EPS documentation (for example, a key element is missing in the response message)
A response message is not in JSON format (for example, a response message is in HTML format)
Other exceptions, errors, unknown behavior, or breaks

Create Booking request should be followed up with a Retrieve Request that includes:

The original value of affiliate_reference_id and email used in the Create Booking request.
Or, the value of itinerary_id and links.retrieve.href returned in Create Booking response.

The status of the booking can then be retrieved except the result for new bookings might delay by up to 90 seconds.

Recommended Procedure

Always send `affiliate_reference_id`

Generate a unique affiliate_reference_id for each customer's booking. If resending the same request details (e.g. due to a failed attempt), the same affiliate_reference_id should be used. This prevents accidental duplicate bookings. When sending a new booking request, the API will not respond until the booking is either confirmed or refused. The majority of responses are returned within a few seconds. However, a small number of bookings can take up to several minutes to process & generate a response.

Monitor bookings that do not resolve quickly

Rapid connects to external systems to make reservations in real-time. The dependent systems could be the different hotels’ Reservation Systems, Front Desk Reception Systems, Credit Card Processor, or Fraud Detect Systems. 98% of bookings can complete the process within ~13 seconds. However, if you did not receive the booking response after 90 seconds, check the progress of the booking with a Retrieve Request, using the same affiliate_reference_id that was sent with the booking. If the reservation is still in progress or if the reservation has failed, you will receive the 404 error "Itinerary was not found with provided request." After receiving this message, you should attempt your booking request again with the same affiliate_reference_id. If the reservation is still being completed, you will see a 400 error with the message "An itinerary already exists with this affiliate reference id." If this error has returned, you can Retrieve the booking again to see if the reservation details are ready to be viewed.

The Retrieve API may return errors or an incomplete response when a reservation is being processed. Retrying the Retrieve call later will recover 99.992% of errors. Otherwise, follow-up with EPS Call Center agents for further support.

Booking Disputes

In case of booking disputes related to time-outs, 50x HTTP Code errors or other infrastructure issues, it will be required to share the following:

Booking request and (if possible) response, including the headers
Log of the 90 second later Retrieve Booking request and response

More error handling guidelines are available at this link.

Log into your EPS Support account to view User interface example , Pseudocode to handle bookings and Integration plan examples.