Error Handling

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 with 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.

Building these errors are required. The error descriptions must be the same as shown below.

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.

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 are returned after pushing availability, restriction, or rate updates.

For instance, if an error like Hotel not found for HotelCode is detected in your OTA_HotelAvailNotifRS or OTA_HotelRateAmountNotifRS, 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. Inform us If your booking channel requires additional error responses to trigger this mechanism

Your system should have a strong error handling process that can queue and resend reservation requests.

Ensure that your system waits for a response from SiteMinder before sending additional reservation requests for the same site. Set an appropriate timeout duration, between 60 and 120 seconds, to allow requests to complete before retrying. This prevents unnecessary retries and ensures smooth communication.

If the response contains an OTA message with an 'Error' element, then the reservation cannot be processed because some data is invalid. See below Common Error Responses. The reservation request message will not process until the error is fixed. In this case, do not retry sending the reservation request until the issue in the payload is fixed. Remove the request from the queue.

4xx errors indicate that the request sent to SiteMinder is invalid. These errors should not be retried, as resending the same message will continue to fail. The partner must correct the payload, structure, or authentication details before attempting to send the request again. For a complete list of common 4xx errors and how to address them, refer to the HTTP Error Handling page.

5xx errors indicate a temporary issue on the server or an upstream dependency. These errors are usually recoverable, and partners are expected to implement a retry strategy. We recommend an exponential backoff approach (5s → 10s → 20s → 40s → then every 1 minute) until a minimum timeout of 30 minutes is reached. If delivery still fails after the retry period, please contact SiteMinder’s Application Operations team. More information on common 5xx responses is available in the HTTP Error Handling page.