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:Envelopexmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> <wsse:Securitysoap: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:PasswordType="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_ReadRQxmlns="http://www.opentravel.org/OTA/2003/05"Version="1.0"EchoToken="abc123"TimeStamp="2025-08-09T21:32:52+08:00"><!-- ... other elements and attributes have been omitted for brevity ... --> </OTA_ReadRQ> </soap:Body></soap:Envelope>
Message Size Limit and Bundling Best Practices
Size limit
pmsXchange has a message size limit of 2MB. Any messages larger than this will not be processed, and you'll receive a SOAP fault in response.
Messages larger than 2MB must be divided into smaller parts or optimized for bundling.
<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header/> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Server</faultcode> <faultstringxml:lang="en">Unable to process message. Payload too large</faultstring> </SOAP-ENV:Fault> </SOAP-ENV:Body></SOAP-ENV:Envelope>
Bundling Updates
Rate, Availability, or Restriction updates should be bundled when the values for consecutive dates are the same. For example, if you are changing a rate of $120 from July 1 to July 14, you should bundle this into a single message using the Start and End attributes.
The best practice for ARI messages is to include only one room and one rate code, along with all the dates that have changed for that room/rate combination. Try to avoid sending small requests for individual dates.
You can also bundle messages using day-of-the-week flags, which allow you to specify which days of the week the update applies to within a given date range.
This Rate message has consolidated the consecutive dates into one single RateAmountMessage.
This request contains 2 different Rate message 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 message with different date ranges that can be consolidated into one single OTA_HotelRateAmountNotifRQ because they are both for the same room rate combination.
When sending a full flush, please keep updates focused on a single room or room/rate combination and include as many dates as possible in each request. We prefer receiving one large update/EchoToken with many dates for that room/rate combination, rather than several smaller updates/EchoTokens with just a few dates each.
Request messages (Availability, Restrictions & Rates) should only include data relevant to the specific action being performed in your PMS (only the data that has changed since the last update).
For example, if a user changes the availability of a room to 4 on 2025-11-08, only send the availability update—no other rate or restriction messages, and do not include unchanged dates. Even though the OTA_HotelAvailNotifRQ message allows for both availability and restrictions, please focus solely on the changes.
Additionally, these updates must be sent to pmsXchange V2 as close to real-time as possible, ideally within 2 minutes of the change occurring in your PMS.
Non-delta updates and frequent full flushes within a 24-hour period are not permitted, as they can negatively impact the performance of the SiteMinder production environment. You should only perform a full data flush when sending the initial updates for a new hotel connection. After that, only delta updates should be sent.
All 'Inventory API' requests made through pmsXchange must not contain overlapping dates. Each date range within a single message should be unique for each Inventory Code/Rate Code combination.
