Integration Requirements
Last updated
Was this helpful?
Last updated
Was this helpful?
As outlined in the API Services Terms of Use Agreement, these guidelines ensure the efficient and proper use of the SiteConnect API.
All OTAs that integrate with SiteMinder must adhere to the following requirements. OTAs with existing integrations may need to update their setup to comply. Due to the growing number of OTA installations, SiteMinder can no longer accommodate exceptions.
Failure to comply with these guidelines may result in the deactivation of the OTA interface. If non-compliance is not resolved within three months of notification, SiteMinder reserves the right to disable the interface until corrections are made. In cases where non-compliance poses a risk to SiteMinder's production environment, the interface may be disabled immediately.
The SiteMinder Web Service is based on the Open Travel Alliance (OTA) specifications for version 2010A. Although this document attempts to be technically comprehensive it is expected that the connecting system’s developers be familiar with the OTA specifications found here: .
SiteMinder supports TLSv1.1 and above. The production URI must use HTTPS. SiteMinder does not support self-signed SSL certificates.
Encryption should be provided by the transport layer via HTTPS. Each message contains a WS-Security (WSSE) UsernameToken SOAP header for authentication/authorisation purposes.
Passwords must be at least 8 characters long and should include a mix of uppercase and lowercase letters, numbers, and at least one special character (e.g., ! @ # ? ]).
Avoid using “<”, “>”, “&”, “““, and “'” in passwords or usernames, as these characters can cause issues with the Web Service.
All communication between SiteMinder and the Booking Channel must use SOAP messages transmitted over secure HTTP (HTTPS). These messages include a SOAP Security header for authentication and a SOAP Body containing the OTA message. The communication operates through synchronous request/response pairs, where each message is considered atomic—processed entirely or not at all by the Web Service.
All SOAP XML requests to SiteMinder must have a Content-Type of 'text/xml; charset=utf-8'. Other Content-Types will not be accepted.
Partners should provide a single URI endpoint for all messages. If not possible, SiteMinder can handle up to two URIs (one for the Rooms and Rates and one for the Availability, Restrictions and Rate PUSH).
The HotelCode is a unique identifier provided by the booking channel, and it must be unique for each property per channel.
SiteMinder supports two regions for reservation delivery: APAC (Asia Pacific) and EMEA/AMERS (Europe, Africa, Middle East & Americas). Your connection should be capable of sending reservations to different endpoints.
Most properties will be in their specific production region, but exceptions may occur, particularly with Whitelabel partners. As a result, APAC properties might be in the EMEA/AMERS environment, and vice versa.
EchoTokens are crucial for all requests made over SiteMinder. Each EchoToken must be unique per request to ensure that every request can be individually identified for troubleshooting in both testing and production environments. Every request from SiteMinder will include an EchoToken, and the Booking Channel's response must include the same EchoToken as received.
The TimeStamp format must follow ISO 8601 Date and Time standards. There are two ways to handle time zone offsets:
UTC time is indicated by a "Z" at the end (e.g., 2021-11-05T13:15:30Z for UTC time).
Local time includes a time zone offset (e.g., 2021-11-05T08:15:30-05:00 for US Eastern Standard Time, which is 5 hours behind UTC).
All SOAP XML requests to SiteMinder must be minified, containing no line spacing or newline characters. Keeping the XML on a single line helps our support teams extract messages from logs more efficiently.
Your application must include robust error handling, with a queuing mechanism and a reliable retry strategy. Refer to the documentation for more details.
Ensure that your EchoTokens are highly unique to facilitate quick and efficient log searching for troubleshooting. Using GUIDs (Globally Unique Identifiers) is recommended. For more information, refer to the guidelines.