iOLX provides a single service with access to hotel rates and booking.
\n\nSets of hotels can be retrieved from single source or multiple sources depending on the profile created on iOLX.
\n\nWorkflow starts with hotel shopping (search) process which sends a request to obtain hotel availability and price for the traveller’s criteria.
\n\nThe traveller then selects a hotel from the list of hotels and required criteria.
\n\nBooking creation, cancellation and retrieval can be done through different sets of API calls.
\n\nThe samples in this project provide the endpoints for you to develop.
Credentials will be provided for you.
The iOLX webservices credentials can provide access to multiple suppliers for a single client. With the same connection, we can provide access to directly to the hotel (switch) or act as distributor.
\n\nEach set of credentials (Client) will have a unique list of properties available to it based on rules and conditions linked to their credentials. One set of credentials can link to multiple suppliers and hence it is important to be able maintain a relationship between the SOURCE ID/hotels returned in the booking response and who the client will pay. If this is not possible, we will issue separate credentials for each source.
\n\nIt is also important that you are downloading data from our hotel List as this list will be different per set of credentials.
\n\niOLX does not support searches based on location data, you must search by hotel codes. It is your responsibility to ensure hotels are correct mapped to your data.
\n\nGIATA has all hotels mapped against supplier code iol_iwtx. Vervotech also provides a mapping service to our hotels.
\n\nin the case of 1 & 2, the roomtype codes and contracttokenid are static and will be the same for all sessions. When booking multiple rooms, it is fine to mix and match rooms and ContracttokenID (Rateplans).
\n\nin the case of 3, the contracttokenID is dynamically created for each search. This means the same roomtype and rateplan combination could have a different contracttokenid for each search.
There are limitation on booking; when booking multiple rooms are only possible where all rooms have the SAME contracttokenID.
Access to live data credentials will only be given once certification is complete.
\n\nA questionnaire will be provided with the test credentials.
\n\nPlease request & READ the questionnaire prior to beginning your development as that contains helpful details for development.
\n\nPlease give IOL at least 2 weeks’ notice of expected completion date of integration for us to book you a certification slot. Please allow 2 weeks for certification process to be completed.
\n\nAPI Name | Description |
Basic Search Function, will return all available rates for hotel(s) searched. Response includes information on each rate returned including cancellation policy but not daily rates. | |
Validate the rate and availability fopr a specific rate | |
API will return hotel details including description, images, local payments | |
API will create booking on iOLX repository and the supplier's repository | |
API will cancel booking on iOLX repository and the supplier's repository | |
Will return a list of bookings | |
Will return all booking details | |
Pull a list of hotels available through the connection |
The following are elements common to all requests.
\n\nEach Request required a Profile element which contains the credentials provided for that client.
\n\nThis will consist of the following:-
\n\nThis value must be specified within the profile and will be returned to you in the response. This should be quoted in any correspondence to Illusions XML Support.
\n\nIt is recommended that the same number be used for the entire booking flow/user session.
\n\nAll dates are in format of YYYYMMDD e.g. 7 November 2017 will be 20171107
\n\nWe maintain a fixed list of mealplans
\n\n| **MealPlanCode** | **MealPlan** | **Mealplan Description** | |\n| --- | --- | --- | --- |\n| 7 | BB | Breakfast | |\n| 11 | HB | Half Board | |\n| 14 | FB | Full Board | |\n| 17 | AI | All Inclusive | |\n| 28 | RO | Room Only | |\n| 12 | HB+ | Half Board Plus | |\n| 15 | FB+ | Full Board Plus | |\n| 18 | AI+ | All Inclusive Premium | |\n\nIt is important to understand that iOLX does not have a charge type of Infant, these must be added as Charge Type = CHD with the appropriate age.
\n\nInfants must be included in the search/booking request to ensure they are priced/booked.
\n\nInfants not included in the search/booking request may result in additional charges at check in.
\n\nHotels often have important messages that must be displayed to the end user. This included fees payable at the hotel.
\n\nThe are returned in the HotelDetailsRequest as static data, or from the Price Check step.
\n\nIt is required that these are displayed to the end user as part of your booking flow.
\n\nIt is the XML users responsibility to ensure these are communicated to the customer.
\n\nMany properties will have prices based on the country of residence of the passenger. This is the country where the client is legally residing, not necessarily their nationality.
\n\nIt is mandatory to specify the country of residence (tag name = Nationality) of the passenger in all searches and all bookings.
Important:
Please make sure your serializer/mapping is configured properly and if
we add new tags to the response model at any level(to any endpoint) this should
not break your code/application. So if there is a new tag but you don’t have it
in the typed model just ignore and get what you can, what you already mapped.