FAQ
The Partner Integration Team has put together a list of common questions we get from our partners developing integrations to the SMX for Apps API.
We ask that you bookmark this page and refer to it regularly, as many questions you might have will likely be answered here. Below we've broken up the FAQ into sections related to the API's different parts.
If your question is not listed here, please get in touch with the Partner Integration team via email.
General
Which customers can connect through SiteMinder Exchange
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.
Are all PMSs listed in your website able to connect through SMX?
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 PMS List in our web, does not imply that the PMS is available in SMX. The PMSs connected to SMX will have a ‘Hotel App Store’ logo. You can also find the list here: SMX PMSs Reservations Capabilities Table
For RMSs (Revenue Management System) connecting to SMX (SiteMinder Exchange). What is the difference between pmsXchange API and SMX API?
For RMSs connecting to both pmsXchange and SMX API, please note the difference: - pmsXchange API is used to send Rate updates to the property’s SiteMinder Platform. - SMX API is used to receive Reservations.
Please 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.
Reservation API
Do I need to certify to receive data from each data publisher individually?
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.
How are messages sent?
SMX uses SOAP XML messages to transmit data to the connecting application. You can find samples of these messages in the Reservation XML Samples section.
When will I receive reservation data?
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).
How do I know what was modified?
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.
How do I receive historical data?
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.
What is the difference between the ResGuest and ResGlobalInfo profiles?
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.
I didn't receieve data that I am after. How can I get the missing data?
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. Please refer to the Error Handling section of the documentation for more details.
Can you send reservation data in a JSON format?
No. SMX is derived from the Open Travel Alliance (OTA) 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.
Why do we need to provide a hotel code to SMX?
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).
Can the ResID_Type and ResID_Value be empty in the OTA_HotelResNotifRS?
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.
Reservation API Integration Process
Could you give me more information about the Certification process?
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. We will also test sending through our Minimum and Maximum content samples.
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.
Availability and Rate API
Last updated