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 and confirmed within Rapid's systems. The infrastructure issue could be:

• The network connection is lost (e.g. no response returned)
• Server-side error is returned (e.g. HTTP Code 500 or 503 is returned)
• A bad network gateway is observed (e.g. HTTP Code 502 is returned)
• Network gateway timeout is observed (e.g. HTTP Code 504 is returned)
• A response is not following the Rapid documentation (e.g. a key element is missing in the response message)
• A response message is not in JSON format (e.g. 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 and 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 is 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.99% of errors. Otherwise, follow-up with Rapid 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 Rapid Support account to view User interface example, Pseudocode to handle bookings and Integration plan examples.