Understand the technical and operational requirements for using the pmsXchange API, including performance standards.
Last updated
Was this helpful?
Guidelines
As outlined in the API Services Terms of Use Agreement, these guidelines ensure the efficient and proper use of the pmsXchange API.
All PMS/RMS/CRS that integrate with SiteMinder must adhere to the following requirements. PMS/RMS/CRS with existing integrations may need to update their setup to comply. Due to the growing number of PMS/RMS/CRS installations, SiteMinder can no longer accommodate exceptions.
Application General
SOAP Message
All SOAP messages communication between SiteMinder and the PMS/RMS/CRS must be 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.
Content-Type
All SOAP XML requests to SiteMinder must have a Content-Type of 'text/xml; charset=utf-8'. Other Content-Types will not be accepted.
File Upload Size
Uploaded messages must not be larger than 2MB (uncompressed). Messages received that are greater than this size will not be processed and a soap fault will be returned. Messages larger than 2MB will need to be broken down into smaller messages or the updates bundled more effectively.
SSL/TLS
pmsXchange API supports TLSv1.2
API General
EchoTokens
EchoTokens are crucial for all requests made over pmsXchange. Each EchoToken must be unique per request to ensure that every request can be individually identified for troubleshooting in both testing and production environments. This token will be returned in the response.
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 Universally Unique Identifier guidelines.
TimeStamp
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).
Line Spacing
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.
Updates must be sent to SiteMinder as close to real-time as possible, ideally within 2 minutes of the change occurring in the PMS. Sending updates promptly ensures accurate and timely synchronization across systems.
Responses and Timeouts
Ensure that your system waits for a response from SiteMinder before sending additional 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.
Queuing Mechanism
Implement a queuing mechanism in the PMS to manage outgoing messages during periods of connectivity loss with SiteMinder, such as network disruptions or scheduled maintenance. Retain messages in the queue and resend them automatically once connectivity is re-established.
Size Limit
pmsXchange has a 2MB size limit for messages. Messages exceeding this limit must be divided into smaller parts or optimized for bundling. Any message larger than 2MB will not be processed and will result in a SOAP fault response:
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring xml:lang="en">Unable to process message. Payload too large</faultstring>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Delta Changes
Requests for availability, restrictions and rates messages must only include data relevant to the specific action in the PMS (i.e., only the data that has changed since the last update).
For example, if a user updates the availability of a room to 4 for stay-date 2025-11-08, please send only the availability change. Do not include restriction or rate data, and exclude any unchanged dates or room rates. While the OTA_HotelAvailNotifRQ message allows both availability and restrictions, updates should focus solely on the required changes.
Delta Updates will be strictly enforced in Production during the Pilot phase.
Please ensure your PMS is handling "changes only" updates push.
Frequent flushes or duplicated updates are not acceptable.
Availability, restriction and rate updates must be bundled when consecutive dates have the same values. For example, if the rate is updated to $120 from July 1 to July 14, combine this into a single message using the Start and End attributes.
For ARI messages, it is best practice to include only one room code (for availability) or room/rate code combination (for restrictions and rates) in the requests. Include all changed dates for that room or room/rate combination in a single request, avoiding multiple small requests for individual dates.
You can also bundle updates using day-of-the-week flags, allowing you to specify which days the update applies to within the given date range.
This request has consolidated the consecutive dates into one single RateAmountMessage.
This request contains 2 different Rate messages that can be consolidated into one single OTA_HotelRateAmountNotifRQ because they are both for the same room rate combination.
First RateAmountMessage is for weekend rate.
Second RateAmountMessage is for weekday rate.
This request contains 2 different Rate messages with different date ranges that can be consolidated into one single OTA_HotelRateAmountNotifRQ because they are both for the same room rate combination.
This refers to sending a complete set of data for availability, restrictions and/or rates for a specific room (for availability) or room/rate combination (for restrictions and rates), regardless of whether the data has changed. Full flushes should only be used in exceptional cases, such as during the initial sync, when recovering from a system issue, or if there is a significant mismatch between the PMS and the SiteMinder platform.
Non-delta updates and frequent full flushes within a 24-hour period are strictly prohibited, as they can significantly impact the performance of the SiteMinder production environment. Full data flushes should only be performed when sending the initial updates for a new hotel connection. Once the initial updates are complete, only delta updates must be sent to ensure efficient processing and system performance.
Include as many dates as possible in each request for that specific room or room/rate combination, following the bundling updates guidelines. It is preferred to send one large update (with a single EchoToken) containing all dates that share the same values, rather than multiple smaller updates with only a few dates each. By bundling updates effectively, you can optimize message size and ensure efficient processing.
All 'Inventory API' requests made must not contain overlapping dates. Each date range within a single message should be unique for each room (for availability) or room/rate combination (for restrictions and rates).
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.
