Error Handling
Responses to SiteConnect
Errors must be returned within a 'SOAP Envelope' and use the defined response message container depending on the message being responded to. See the relevant parts of our specification within the Rooms and Rates, Availability and Restrictions and Rates sections for more information about each error response message.
If the error is specifically related to application-level errors, do not respond to any other error types (HTTP, etc.). If you have server-level issues, then it is OK to respond with HTTP standard error codes.
It is expected that your booking channel has a robust error handling process in place. This includes a queuing mechanism and a robust retry strategy.
An error response must contain a short error description to assist our support teams.
Sample Error Response
Mandatory Error Responses
Building these errors are required. The error descriptions must be the same as shown below.
| Error Description | Mandatory |
|---|---|
Invalid Username and/or Password |
|
Hotel not found for HotelCode=XXXXXX |
|
Room type code not found for this hotel |
|
Rate code not found for this hotel |
|
Invalid included occupancy
Optional: the error Invalid included occupancy can be combined with expecting N (e.g. Invalid included occupancy: expecting 2). This provide more detailed information about the correct value that need to be configured in the room rate mapping.
Invalid number of adults
This error will validate against the # of BaseByGuestAmt nodes received in the OTA_HotelRateAmountNotifRQ. If you have set the Max Occupancy to 5, then you must expect 5 BaseByGuestAmt indicating the price per pax. If you receive more or less, then the error Invalid number of adults must be sent to alert the hotelier to check the Max Occupancy setting in SiteMinder. BaseByGuestAmt nodes must match the Max Occupancy value for that room rate combo.
Optional: the error Invalid number of adults can be combined with expecting N (e.g. Invalid number of adults: expecting 5). This provide more detailed information about the correct value that need to be configured in the room rate mapping.
Auto-Disable Mechanism
To ensure data accuracy and system integrity, our error handling includes an auto-disabling mechanism that temporarily disconnects a property or specific rooms and rates when certain errors occur.
For instance, if an error like Hotel not found for HotelCode is detected, the entire property connection is disabled. In cases where errors such as Room type code not found for this hotel, Rate code not found for this hotel, Invalid included occupancy, or Invalid number of adults occur, only the affected rooms or rates are disabled.
Once disabled, the system stops retrying the connection indefinitely and sends an email notification to the property with details about the action taken, the error encountered, and steps for resolution. If your booking channel requires additional error responses to trigger this mechanism, please inform us.
This mechanism relies on the error descriptions to function correctly. Ensure that the descriptions used match those listed above.
Responses from SiteConnect
If the response contains an OTA message with an 'Error' element then the reservation can not be processed because some data is invalid. This could be, for example, if required data is missing or if the credentials/hotel code are incorrect and the message will not process until the error is fixed. If the error is that a required element or attributes are missing, the implementation will need to be adjusted to send the required data. If the error is to do with credentials, check that the correct username/password is sent. If the error is an invalid hotel code, contact the hotel to make sure they have the correct hotel code configured in SiteMinder.
Sample Error Response
Common Error Responses
Handling HTTP 500
If the response is a HTTP error response code in the 500 range then it is expected that the connecting OTA will implement a retry strategy until they are successfully delivered or a pre-defined timeout period is reached, for example, 30 minutes. Below we've provided a table that outlines the expected behaviour for each 500 range error. In the case that an update cannot be delivered within the timeout period, a case should be raised with our Application Operations team.
Refer to Handling HTTP 500
Last updated