Availability, Rates, and Pricing Schemes can be managed by 3rd party systems. Channel Management, Yield Management, data import, and other applications are possible using WebHotelier's API.
The functionality described in this document requires a Hotelier API account (one account per property).
A 3rd-party channel manager can control rates & availability in WebHotelier via the API. Below we describe the minimum requirements necessary to set up WebHotelier as a channel: Mappings, Availability & Rates management, and Booking Import.
The channel manager ("CM" from now on) needs to map certain property data in its system in order to be able to use the management APIs (rates & availability).
a) The CM needs to map WebHotelier room types to the room types defined in CM. The CM can employ a semi-automated mapping method by retrieving WebHotelier room types programmatically and do the mapping using simple form controls.
To retrieve property room types, the CM can use the Room Listing method.
b) The CM needs to map WebHotelier rates to rates defined in CM. The CM can employ a semi-automated mapping method by retrieving WebHotelier rates programmatically and do the mapping using simple form controls.
To retrieve property rates, the CM can use the Rate Listing method. To simplify mapping, the CM can also retrieve additional rate information using the Rate Info method to get additional rate data that can help with the mapping process.
To manage room availability, the CM can use the Availability Management method. This method allows for setting and updating room availability using the room type codes that are mapped as described in the Mappings section.
The API also allows for:
To manage pricing, the CM can use the Rates Management method. This method allows for setting and updating rate pricing using the rate codes that are mapped as described in the Mappings section.
The API also allows stop selling a rate (CLOSE-OUT) or setting minimum stay overrides per rate on a daily basis.
Rates in WebHotelier are organized per room type. They may be derived from pricing schemes or other rates or higher level structures, but from an external system they should be viewed as a unique standalone unit:
Each rate is standalone and unique.
Only valid occupancy combinations are stored:
ROOM TYPE A
RATE 1
RATE 2
ROOM TYPE B
RATE 3
RATE 4
RATE 5
ROOM TYPE C
RATE 6
RATE 7
Rates may be independent. Room types use a rate
and inherit pricing compatible with the room occupancy:
RATE 1
ROOM TYPE A
ROOM TYPE B
RATE 2
ROOM TYPE A
ROOM TYPE B
ROOM TYPE C
RATE 3
ROOM TYPE B
ROOM TYPE C
Pricing in WebHotelier is occupancy based. This means that for a every valid occupancy combination for a particular room type the system stores or generates a single distinct price.
As an example, a room with maximum 3 persons can have the following price combinations (adults+children):
1+0, 2+0, 2+1, 3+0
that is up to 4 different prices in total
Whereas a room with maximum 5 persons can have the following price combinations:
1+0, 2+0, 2+1, 2+2, 2+3,
3+0, 3+1, 3+2, 4+0, 4+1, 5+0
that is up to 11 different prices in total
Things can get complicated after that and of course there are other factors such as minimum occupancy allowed, some room types may not allow children, etc.
To simplify things, the API's only requirement is for the CM to provide a price for the minimum valid occupancy. WebHotelier will generate the rest of the combinations.
The CM can also send combinations not applicable for a particular rate. WebHotelier will just ignore those combinations and only use the valid ones.
Therefore, The CM can choose to use as simple or as complicated pricing as it wants to:
The CM needs to be able to import bookings generated by WebHotelier and update availability accordingly. The CM can register an endpoint to receive notifications or full booking bodies as they happen. For more please see Booking Push.
The CM does NOT need to update WebHotelier's availability after a booking has been made. The CM can skip updating availability in WebHotelier if it receives a booking from there because the system would already have lowered the available rooms and would be up to date. However, optionally, it can do so.
WebHotelier also provides an alternative manual syncing mechanism for downloading bookings. For more please see Pending Bookings.
In order for the CM to confirm proper integration, we provide rate and availability feeds that can be used for that purpose. The CM can retrieve the current state of availability and pricing in WebHotelier for all rooms and rates or specific rooms and rates and check against its current state.
The two API methods that implement this functionality are the Availability Feed and Rates Feed.
Yield management systems ("YM" from now on) can use WebHotelier's API to modify pricing automatically instead of the hotelier having to manually update prices based on recommendations.
A YM can use the Pricing Schemes method to to automatically change the daily rate policy. The only caveat is that the scheme (or "level") names on both systems should have the same names.
A YM can also directly modify pricing, skipping pricing schemes entirely, using the Rates Management method.
If a hotelier migrates to WebHotelier, room availability and rate pricing can be imported from a 3rd party system using the above described methods. If you require assistance, please contact us. Offline data import methods are also available if the source system has the ability to export data in XML, CSV, JSON or a spreadsheet.
Pricing and availability can be exported to 3rd party systems for analysis, yield management, price comparison or migration purposes, etc. We provide rate and availability feeds that can be used for that purpose.
In order to import and permanently store data exported from WebHotelier APIs, you must have written hotelier consent.
The two API methods that implement this functionality are the Availability Feed and Rates Feed.
