Skip to content

Booking Failure Handling

Important Note

  1. The Travlinq OTA API internally invokes various supplier(GDS, aggregators,consolidators, LCC, NDC, Hotels etc) APIs.
  2. Sometimes, we do not receive the proper API response from our upstream suppliers, or sometimes it can take additional time at the supplier end. Also, the suppliers may update the ticket numbers after a few minutes.
    1. In such cases, the Travlinq OTA API will not be able to return the proper response or may time out.
  3. In case you do not receive a proper status from the Travlinq OTA API, do not assume that the booking has failed.
  4. The below method describes an approach which you should implement at your side to handle such scenarios.
    1. In spite of multiple attempts, in case of any ambiguity whether a booking has failed, the recommended approach is to verify with the supplier portal, before taking any actions on the booking failures.
  5. This is to ensure that there is no inconsistency between the supplier system, VE system and your system, and avoid any financial impact in case the booking has been ticketed on the supplier system, but not updated in your system.

Async Retry Handling

This service provides endpoints for fetching data asynchronously. Each request has maximum 25s lifetime then client has to use fetch endpoint and retrieve the relevant response.

For more information: Asynchronously Data Fetching

Booking API call

  1. Invoke the Booking API of Air or Non-Air Products.
  2. If there is no response, null response, empty response, network timeout.
    1. Then invoke the Booking Retrieve API
      1. If Booking Retrieve API returns booking details in response, then consider it as a successful response, and update the details in your database.
      2. Else if the Booking Retrieve API does not return proper response, then repeat step 2(a), at 10 second intervals, for at least 2 minutes from the initial Booking API call.
      3. If there is no proper response after multiple attempts, then use the Scheduler approach.
  3. Else if you receive a proper response
    1. If the Book Response is with booking status as TICKETED, PNR FAILED or ON HOLD for AIR and “CONFIRMED” status for Non-Air products, then consider the book response as successful and update the respective status in your database.
    2. If the Book Response is with booking status “OK TO TICKET” and "IN PROGRESS" for Air and “ON REQUEST” and "IN PROGRESS" for Non-Air products, then go for Scheduler approach

Scheduler Approach

  1. Invoke the Booking Retrieve API every 5 minutes
    1. If the Booking Retrieve Response is with booking status as TICKETED, PNR FAILED or ON HOLD for Air and “CONFIRMED” status for Non-Air, then consider the book response as successful and update the respective status in your database.
    2. If booking status is still “OK TO TICKET” and "IN PROGRESS" for Air and “ON REQUEST” and "IN PROGRESS" for Non-Air or no/null/empty response then continue with Step 1 from Scheduler Approach.
  2. After 30 minutes from the booking time, if you still get the booking status as “OK TO TICKET” and "IN PROGRESS" for Air and “ON REQUEST” and "IN PROGRESS" for Non-Air or no/null/empty response, then verify the status of the booking on supplier portal before taking any actions on the booking failures.
  3. Here, we recommend adding a notification mechanism for you to keep track of such bookings to verify the same on the supplier end.