FAQ
Frequently Asked Questions about SiteMinder Exchange API
Last updated
Was this helpful?
Frequently Asked Questions about SiteMinder Exchange API
Last updated
Was this helpful?
Any hotel who is using a SMX certified PMS and a SMX certified application can use the interface without the need to be a SiteMinder customer.
The PMSs listed on our website are connected to our Channel Manager, but not all have an agreement to publish any data to SMX.
pmsXchange and SMX are 2 different products that need to be built separately, and being in our , does not imply that the PMS is available in SMX. The PMSs connected to SMX will have a ‘Hotel App Store’ logo.
For RMSs connecting to both pmsXchange and SMX API, note the difference: - pmsXchange API is used to send Rate updates to the property’s SiteMinder Platform. - SMX API is used to receive Reservations.
Note that both connections will have different Hotel codes used to activate data flow. Consult with the relevant SiteMinder team for questions about the Hotel Code used.
No. SMX is built on the mentality of 'develop once, connect to many'. Once your connection is certified with SMX you will be able to connect to all available data publishers. SMX will handle any message conversion required.
Data publishers should send an updated version of the reservation message when it is modified in their system. This can include events such as a reservation status being adjusted to In-house (guest is checked in), a guest has been moved to another room, or a modification was received from the booking source (ie: Booking.com).
Data publishers will provide the full reservation details after the modification has been made. This means you will also receive the complete reservation details again.
It is important to note that SMX will not compare the changes that have been made and cannot provide a 'summary' of the changes.
In most scenarios, the data publisher can simply push the data through to SMX, which will pass it on to you. However, you will need to discuss this with the data publisher to determine if they are able to push through historical data.
ResGuest: This will contain the details of the 'staying' guest if provided by the data publisher.
ResGlobalInfo: This will contain the details of the 'booking' customer, and may also contain details of business, wholesaler or travel agent information
It is a good idea to ensure you can use both the ResGuest and ResGlobalInfo profiles, as it cannot be guaranteed that both will always be sent.
SMX can only provide you with reservation data sent by the data publisher. Your system is expected to be able to return an appropriate Success+Warning response for missing data or an Error message if a reservation message cannot be processed. Refer to the Error Handling section of the documentation for more details.
We ask you to provide us with an identifier for the hotelier within your system as this ensures that the HotelCode attribute within each message is unique to your system and in a format you are able to handle. As we connect to multiple data publishers, there is the possibility that duplicate codes will exist between these data publishers (ie: HOTEL1 may exist in 2 different data publishers).
HotelReservationIDs / ResID_Type and ResID_Value are mandatory in our Response specs and cannot be empty. This section should not be taken from the reservation request XML received (In case it is not present in the Request XML). This is the HotelReservationID generated in your application after you confirm/create this reservation in your portal. You should be passing the ID generated in your extranet. Most partners use the same ID received under UniqueID as their ResID_Value if your system is not able to generate its own confirmation ID.
The certification process is very straightforward. We will create some reservations (some of them will be modified and/or cancelled) and will verify that all of them will trigger either a successful response or a meaningful error response. Your responses should be well in line with our OTA_HotelResNotifRS specifications.
If some reservations trigger an error (for instance, due to missing data), this error must be as eloquent as possible and it should not impact the HTTP status which should remain at 200. If you have server-level issues, then it is OK to respond with HTTP standard error codes. See our Error Handling specs for more details.
The only thing that is required from your side is to leave your endpoint up and running until we complete certification.
If there's an issue with your responses or some of the reservations cannot be delivered and we don't understand why, we will let you know and once it has been fixed, we will resume the certification. This means you can "fail" it any number of times, the important thing is that at the end of this process, we fixed all the issues.
SMX uses SOAP XML messages to transmit data to the connecting application. You can find samples of these messages in the section.
No. SMX is derived from the industry standards, which uses SOAP XML. At the time SMX was created, JSON was not a supported message format. However, there are plans to introduce a JSON version of the reservation API.