Integration Requirements - READ ME FIRST

Integration Requirements Guidelines

In accordance with the API Services Terms of Use Agreement signed by the PMS/CRS partner before development has commenced these guidelines are in place to ensure efficient and proper use of the pmsXchange API.

The following Integration Requirements must be adhered to by all PMS' that have or wish to have an interface to pmsXchange.

For PMS providers that have already been implemented, the below may require changes to the set up they currently have. Whilst SiteMinder could be flexible in accommodating exceptions in the past, the constant increase in the number of PMS installations and is reaching a level where exceptions can no longer be allowed.

EchoTokens

EchoTokens are essential for all requests being made over the pmsXchange v2 as per the following link - EchoToken, Timestamp and POS.

Linespacing

All Soap XML requests made to pmsXchange should be contained on one line with no linespacing. We ask this to assist our support teams in extracting messages from our logs.

Content-Type

The ‘Content-Type’ for all Soap XML requests made to pmsXchange V2 must be 'text/xml; charset=utf-8'. Any other ‘Content-Type’ will not be accepted.

SSL/TLS

pmsXchange V2 supports TLSv1.2

File Upload Size

Uploaded messages must not be larger than 2MB (uncompressed). You can read more about how we respond to a message larger than 2MB within the 'Developer Guide' on this page.

Bundling Updates

Rate, Availability or Restriction updates must be bundled in instances where the values for consecutive dates are the same. For example, if you are changing a rate of $120 from the 1 July - 14 July you must bundle the message. More information on bundling is included within the 'Developer Guide' on the bundling updates best practice page.

Delta and Actions Performed Only Updates

Request messages (Availability, Restrictions & Rates) must ONLY CONTAIN data relevant to the action being performed in your PMS. For example, if a PMS user is changing the availability of a room in the PMS, you must only send the availability update and no other rate or restriction messages. No unchanged dates should be included in these request messages. More information on each message structure will be contained in the pmsXchange 'Developer Guide'. More details on deltas can be found here.

In addition to this, these updates MUST be sent to pmsXchange V2 in as close to real-time as possible. Updates should be sent within 2 minutes of the change occurring in your PMS.

Non-Delta and Frequent Full Flushes

Updates that are not delta (refer to previous point) and frequent full data flushes within 24 hours is not allowed. These actions could put performance to the whole SiteMinder production environment at risk.
Only perform a full data flush when sending the first updates to a new hotel connection. After that, it should only be delta updates (refer to previous point).

Overlapping Dates

Any 'Inventory API' requests made over pmsXchange v2 should not contain overlapping dates. All date ranges in a singular message should be unique for each Inventory Code/Rate Code combination.

Error Handling / Hotelier Error Awareness

It is expected that your PMS has a robust error handling process whereby errors can be queued and resent. It's also expected that you make hoteliers aware of errors affecting the syncing of their data over pmsXchange. More information can be found below under 'Availability (Restrictions &/OR Inventory) Uploads' and 'Rate Uploads' and within our Error Handling page.

Reservation delivery

This message pertains to the delivery of reservations from pmsXchange to the PMS

Reservation PULL Model

The PMS should never request for reservations more often than:

• Every 2 minutes for a decentralised interface, and no less often than every 5 minutes.

• Every 2 minutes for a centralised interface, and no less often than every 5 minutes. Exceptions to be agreed with SiteMinder.

If upon receipt of a reservation, the PMS system is unable to process it, the reservation XML message MUST nevertheless be accepted by the PMS system and acknowledged as 'Success' or 'Error' back to SiteMinder, regardless of possible errors (for instance if they contain a rate code that is not yet defined in the PMS system or if it is a cancellation for a reservation not found in PMS). The pmsXchange system is only transiting the reservation after it has been made in the distribution channels and will not be able to modify the reservation upstream. This can be achieved of course by using default values in case of mismatching codes or ignoring cancellations for which there is no reservation in the PMS and responding to the message successfully. In case of application of Default codes, the PMS should notify the user so that any code mapping error can then be rectified.

Availability (Restrictions &/OR Inventory) Uploads

These uploads include all messages pertaining to the transfer of inventory counts and restrictions with the PMS capability, pmsXchange compatibility, and as described in the transfer of availability messages to pmsXchange.

1. The PMS provider MUST ensure that only changes to availability and restrictions, and not full refreshes, are sent. Refreshes should only be sent at most once per day and at times when traffic is low i.e. between midnight and 5 am. Only in exceptional circumstances should additional full refreshes be sent.

2.  Identical changes in availability for consecutive days should be condensed into one message wherever possible. For instance, if the change in inventory counts for room type SGL is = 10 for Jan 1st, Jan 2nd and Jan 3rd, the PMS provider should send one single message to pmsXchange with start date Jan 1st and end date Jan 3rd rather than 3 daily messages.

3. The PMS will need to establish transaction/error logs to collect error messages generated by the system in case of errors in the transmission of your upload messages. The error log and error messages must be available to the property use for regular checks (to be undertaken by the properties, at a minimum, on a daily basis). For example, if an availability message is rejected by pmsXchange because of erroneous content (for example if it contains a room type code that is not recognised error message. The PMS provider must ensure such message is made available for the property to view and that the property is alerted the transaction was not successful. Upon viewing the error message the property must ensure the appropriate correction is applied as soon as possible and ideally no later than 12 hours from receipt of the message. If no corrective action is taken, and the incorrect message continues to attempt to upload in a loop, SiteMinder will reserve the right to disable the interface till such time as corrective action is taken.

4. It is advisable that the PMS has a queuing mechanism that queue upload messages in case of lack of connectivity with the pmsXchange service or during scheduled release outages. If pmsXchange fails to respond at all, then the messages should be re-sent when connectivity is re-established.

5. pmsXchange v2 only allows Inventory Updates for Room/Rate code combinations that are known to SiteMinder (i.e. have been setup and mapped to the PMS within the SiteMinder Channel Manager). If we receive an Inventory Update that contains a Room/Rate code that is unknown to SiteMinder Channel Manager, the entire Update will fail.

Rate Uploads

These uploads include all messages pertaining to the transfer of rate data from the PMS to SiteMinder

1. For day to day usage, when ARI changes are made, the PMS provider must ensure that only changes to rates, and not full refreshes, are sent. Full refreshes should only be sent at most once per day and at times when traffic is low i.e. between midnight and 5 am. Only in exceptional circumstances should additional full refreshes be sent.

2. Identical changes in rates for consecutive days should be condensed into one message wherever possible. For instance, if the change in rates counts for room type SGL is = $100 for Jan 1st, Jan 2nd and Jan 3rd, the PMS provider should send one single message to pmsXchange with start date Jan 1st and end date Jan 3rd rather than 3 messages.

3. The PMS will need to establish transaction/error logs to collect error messages generated by the system in case of errors in the transmission of your upload messages. The error log and error messages must be available to the property user for regular checks. For example, if a rate message is rejected by pmsXchange because of erroneous content (for instance if it contains a rate code that is not recognised by pmsXchange the PMS provider must ensure such message is made available for the property to view and that the property is alerted the transaction was not successful. Upon viewing the error message the property and/or PMS must ensure the appropriate correction is applied as soon as possible and ideally no later than 12 hours from receipt of the message. If no corrective action is taken, and the incorrect message continues to attempt to upload in a loop, SiteMinder will reserve the right to disable the interface till such time as corrective action is taken.

4. It is advisable that the PMS has a queuing mechanism that queue upload messages in case of lack of connectivity with the pmsXchange service or during scheduled release outages. If pmsXchange fails to respond at all, then the messages should be re-sent when connectivity is re-established.

5. pmsXchange v2 only allows Rate Updates for Room/Rate code combinations that are known to SiteMinder (i.e. have been setup and mapped to the PMS within the SiteMinder Channel Manager). If we receive an Inventory Update that contains a Room/Rate code that is unknown to SiteMinder Channel Manager, the entire Update will fail.

PMS Payment Transaction Sync

The SiteMinder Pay integration with Channel Manager & Property Platform offers customers the ability to process payments for their Channel and Direct Booking reservations, and secure their funds effectively. Currently, customers have to manually record these payments in their respective PMSs. However, Siteminder is launching a new PMS-Pay Transaction Sync feature that enables SM payment transactions associated with a CM reservation in CM or Property Platform to be passed automatically to participating PMSs as a separate "Payment Transaction". This removes the manual effort required to record payments processed by SM Pay to the customer’s PMS, improving user experience and reducing time spent on managing payments. This feature will increase adoption and transaction volumes for us going forward.

The PMSX payment sync feature introduces a new integration API which allows participating PMSs to sync details of SM payment transactions associated with a CM reservation and display it on their own customer interface. Hotel’s will now have visibility of the payments processed via CM in their PMS, which helps them to process invoicing and pending payments in their PMS more efficiently. This feature is a one-way sync which allows participating PMS systems to pull payment details associated with a channel reservation into their system, SM does not pull payments processed via the PMS back to our systems (future functionality).