Integration Requirements
Understand the technical and operational requirements for using the SiteConnect API, including performance standards.
Last updated
Was this helpful?
Understand the technical and operational requirements for using the SiteConnect API, including performance standards.
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.
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.
Endpoints should aim to respond within 1-2 seconds on average, with sub-1-second response times being ideal. When processing Availability, Restrictions, and Rates messages, the endpoint must respond with either a 'Success' or 'Error' message promptly. SiteMinder enforces a 20-second timeout for update requests, but this is a failsafe. Consistent timeouts or prolonged response times should not occur frequently or persistently.
Conduct thorough performance testing on production servers and endpoints to ensure they can scale with the number of hotels connected in production. SiteMinder may push large amounts of data, such as up to 750 days' worth of Availability, Restrictions, and Rates, within a short period. This data load can be significant, especially when multiple properties go live simultaneously or push large updates. Additionally, SiteMinder operates on a set update period, meaning the connection must always be able to accept updates for the agreed period (e.g., up to 365 days from the current day) at all times.
Ensure hotels are informed about any necessary timezone settings within the Booking Channel extranet. SiteMinder pushes Availability, Restrictions, and Rates based on the hotel's local timezone as configured in the Channel Manager, with server timestamps set to GMT for EMEA and AEST/AEDT for APAC. Consider these timezone settings when accepting Availability, Restrictions, and Rates push updates to avoid conflicts during message processing.
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.
Failure to comply with these guidelines may result in the deactivation of the 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.