Since supplier error messages change without notice and are not published by those systems, a full list of messages is NOT KNOWN.

Example error handling flow

  • Log and collect error messages as they occur so you can build your own database of errors.
  • By collecting the handling, category, and message elements in your own system, you'll be able to eventually handle all errors as they occur, including any new messages that are returned from the supplier resources.
Common Error Types
Search Errors Known search, location exceptions, and other common errors
Credit Card Errors Known credit card errors
Reservation Errors Common booking errors
Cancellation Errors Common cancellation errors

Prevent Duplicate Bookings Special logic to prevent duplicate bookings
Pending Stack Trace Supplier messages that indicate a pending booking status
Pending Process Supplier messages that indicate a pending booking status
Price Change Errors How to handle price mismatch or price change errors
PHP, Axis, .NET, JSON Issues Known issues with PHP, Axis, .NET or JSON processes

Errors will indicate:
  • a problem with the request structure. Correct the the request string by checking structure, spelling, closed tags, etc.
  • a problem with the data being sent. Check for accurate parsing of hotel data for the selection.
  • a problem with user input. Alert user to correct input.
  • a problem connecting or interacting with the supplier and third party systems. Supplier issues can be intermittent or prolonged.
Example Logic

By checking handling, category, and message details, most errors are fairly simple to correct.

Read the messages returned to understand the nature of the error, but do not rely on the message itself to determine how it should be handled in your code. In most cases, this text gives a clear explanation for the error as it relates to handling and category details.

Example message: "The selected room rate is no longer available. Price check failed on availability."

<handling>RECOVERABLE</handling> 
<category>PRICE_MISMATCH</category>
Example error handling :
  • handling=RECOVERABLE means the booking can be successful if the error is corrected and the booking resubmitted .
  • category=PRICE_MISMATCH indicates the rate change and verifies why the message states the specific text returned
  • The user must select another room since the price submitted "failed" (changed)
  • The room result must be refreshed to obtain the new rates and re-submit an updated booking query.
  • Do not submit the reservation with a new or changed rate without first having the user agree to any new pricing, especially in the event of a price increase.
  • When allowing the user to agree to the new price, give the user the option to select another room at that property where the price may be otherwise more agreeable AND/OR allow the user an option to search or select a new property for booking.
Connectivity and Communication Issues
  • “Supplier Communication Problem”
  • “Communication failure”
  • “Supplier response is null”
  • “Reservation not processed. Null reply returned”
All of these messages, regardless of the supplier, indicate we have:
  1. Received the reservation request
  2. Attempted to place it with the supply source
  3. Received no response or an error response from the supplier

In these cases, the supplier is experiencing connectivity issues and cannot accept communication until full connectivity is restored, or is unable to complete the reservation due to other issues inside their own network.  In some cases, the error can be recovered by resubmitting the request if the connection issue is intermittent.  If the connection error is prolonged, another supplier selection must be made.

Best Practice

Do not rely on text-matching exception messages to evaluate a course of action.

  1. Identify the specific handling, category, and message for the error
  2. Verify the structure of your request
    • Review well-formed example requests to ensure you are submitting all parameters and values correctly
    • Use our API sandboxes to generate valid requests to compare against your own.
  3. Determine if the error can be resolved with changes from the user
    • Does the user need to select another property?
    • Does the user need to correct their input data?
    • Let the user know an agent will contact them to follow up with the reservation request when handling=AGENT_ATTENTION is returned