LET’S START BUILDING.
Welcome to the SmartHOTEL Sandbox environment. Here you will be able to find all information to setup an XML connection between your product and the SmartHOTEL Channel Manager.
On this website you will be able to find the API specifications to build a connection between your product and the SmartHOTEL channel manager. The API consists of 4 different parts.
This section describes the generic properties in the request and the response messages. Note that these attributes and elements will be omitted from the XML examples in the remainder of the document, but are required in the actual messages! All messages follow OpenTravel model OTA2016A.
This section describes the request and response message flow between OTAs and the SmartHOTEL channel manager. In general this means that the OTA will deliver reservations to the channel manager and the channel manager will update the OTA with rates, availability and restrictions.
This section describes the request and response message flow between a hotels PMS system and the channel manager. in general this means that the PMS can pick up reservations at the channel manager and update the channel manager with rates, availability and restrictions.
This section describes the request and response message flow between a hotels own booking engine and the channel manager. The OBE will request availability from the channel manager and display this on their own front end. Reservations created at the OBE will be pushed to the channel manager.
Please be aware that all three APIs are very specific for their use.
In case you are not clear on which to use, please do not hesitate to contact us.
Please refer to the change log to see the latest changes in our specifications.
FROM IMPLEMENTATION TO TRUSTED PARTNER.
In the introduction email we have sent you, we provided you with all tools you need to develop your connection towards SmartHOTEL.
With that email you received the following:
1. The Api key and password
2. The HTTP header details
3. HotelID (to test against)
4. Endpoints to our sandbox environment
5. Test hotel and login to the extranet for it
As all information is now complete, it is time to start programming the connection with our API. On this page all necessary specifications can be found and we support several different scenarios. In case you are not sure about which set of specifications to use, please do not hesitate to contact us and we will advise you.
In case you support functionality which we haven’t developed, please contact us to see how we can help you out.
It might be that we have the functionality already but not yet support it through the API or that we need to do some small adjustments in our application.
In case you have any questions or remarks please do not hesitate to contact us.
In case you have implemented the OTA specifications, you will receive rate and availability updates from us.
Please forward us your endpoints as we will need to implement these in the database for you and start your services.
In case you don’t send us any endpoints, no testing or certification can be done.
Next step is to test your implementation.
You have a test hotel in our sandbox, here you can either send rates and availability to, retrieve it and send or pick up reservations.
As soon as you are happy with the way everything works you can request a certification.
The final step to get your implementation to our production environment is certification. During this certification we will test the quality of your implementation, see if all message types are implemented correctly and check which functionalities you have implemented. If all is good, we will provide you with endpoints and an Apikey for production environment. In case you have customers waiting already we can start with connecting 1 or 2 as a pilot. In case you haven’t we can help you to find one or two customers to pilot.
Frequent Asked Questions.
Property management systems also known as PMS or Hotel Operating System (Hotel OS). They are computerized systems that facilitate the management of properties, personal property, equipment, including maintenance, legalities and personnel all through a single piece of software. They replaced old-fashioned, paper-based methods that tended to be both cumbersome and inefficient. They are often deployed as client/server configurations. Today, most next generation property management systems favour web and cloud technology and offer their software to clients using a software-as-a-service model.
OTA stands for Online Travel Agency. Examples of OTAs are Booking.com Expedia.com HRS.com etc.
OBE stands for Online Booking Engine. I’t is the tool used by hotels to create a booking platform o their brand.com website.
The API Key and password will be handed out by your SmartHOTEL contact person. You are not able to find it here on this website.
Yes, also a HTTP header is required. Name and value will be provided by SmartHOTEL. More information can be found on the Endpoints page
The occurrence column in the specifications determine which information is mandatory or optional. The possible values and their description can be found in this table
A room can consist of more room plans. The sum of the availability of all room plans in one room will be distributed as the availability for that room to a connected OTA.
If you set the InvCodeApplication to InvGroupingCode we will see InvTypeCode as the ID of a room plan. If InvCodeApplication is omitted then we will see InvTypeCode as the ID of a room.
In the OTA_HotelDescriptiveInfoRS for OBE and PMS specs there are several possibilities for the attributes @MinOccupancy and @MaxOccupancy. In below schema you can find the possible occupancy for a room based on the @MinOccpuancy and @MaxOccupancy.
Please refer to below table to find the exact possibilities:
|@MinOccupancy||@MaxOccupancy||Pricing sent for:|
|2||2||1 & 2 persons|
|2||3||1,2 & 3 persons|
|2||4||1,2,3 & 4 persons|
The rate type will define what kind of rate this rate code is.
There are several values:
Base rate: Calculated rates will be calculated from the base rate.
Default: This is the standard setting for a rate code.
Calculated: This rate will be calculated from the base rate.
Best bar by day: Rate type used for specific setup with RMS systems
No R&A update: This rate will not send any messages to an OTA.
The elements that are not following the standard OTA2016A specifications are as followed.
A placeholder in the schema to allow for additional elements and attributes to be included per Trading Partner Agreement (TPA). Allows extensions to be added to the OpenTravel specification per trading partner agreement. This is integrated to work with RatePlans as mentioned in the OTA specifications in the OTA_HotelRatePlanRS.
After building the connection, the certification process will take place.
This will take up around 60 minutes.
During the certification each step implemented will be tested and approved or disapproved.
When something is not correct, this needs to be adjusted and we will plan a new moment to do the certification.
When all is approved, you are certified and we can proceed to run the first pilot on production.
You can contact us for all your questions regarding our solutions, hospitality and everything else!
In case you have any questions regarding these specifications or the implementation of them, please contact us. We will be happy to help you out.
Address: Einsteinstraat 5,
2811 EP Reeuwijk, the Netherlands
Phone: +31 (0)182 75 11 18
LATEST SPEC UPDATES.
Vault URL for creditcard information
It is now possible for PMS partners to add an [...]
Update version 2.2.1
The OTA_ReadRQ has been updated and an extra note is [...]
Version 2.2 is now live!
The brand new specifications are now live and ready to [...]