The only acceptable value for the Password @Type attribute is http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText. Plain text passwords are acceptable as all communication is done over encrypted HTTP (HTTPS).
Example
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<wsse:Security soap:mustUnderstand="1"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken>
<wsse:Username>USERNAME</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">SECRET</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soap:Header>
<soap:Body>
<OTA_ReadRQ
xmlns="http://www.opentravel.org/OTA/2003/05" EchoToken="ed8835ff-6198-4f38-b589-3058397f677c" TimeStamp="2024-07-06T15:27:41+00:00" Version="1.0">
<!-- ... other elements and attributes have been omitted for brevity ... -->
</OTA_ReadRQ>
</soap:Body>
</soap:Envelope>
Best Practices
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 on 2025-11-08, send only the availability change. Do not include restriction or rate data, and exclude any unchanged dates. While the OTA_HotelAvailNotifRQ message allows both availability and restrictions, focus solely on the 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).
