Introduction: This document aims to address the most commonly asked questions about our APIs, providing clarity and guidance for a seamless integration experience.
FAQ’s:
1)How to create a new Rest API user?
Prerequisite:
DC should be created in MXTS.
RC should be linked to the DC created above.
Please refer /wiki/spaces/DEV/pages/239534085 for further details.
2)What is the reservation creation flow using API inline with MXTS?
Prerequisite:
DC and RC to be used for creating the booking.
Expected stay period (arrival date, duration).
Basic required configurations like applicable rates, rentability and other such conditions that are needed for the accommodation to be bookable.
Solution: Please follow the steps mentioned below:
a) Checking the availability of accommodation using GET availability endpoint.
b) Checking the availability of mandatory addons using GET availability/implies endpoint.
c) Create a reservation proposal using reservation/proposal end point. This endpoint corresponds to the GET rates step while creating the booking via MXTS. It provides the user an idea about the prices associated with the items to be booked along with the accommodation and other rates.
d) Confirm the booking using the confirm reservation endpoint. The user can mention the customer details and confirm the booking. This step corresponds to setting the reservation with provisional/quotation/optional status in MXTS.
3)Is it necessary to follow a,b,c and d from question 2, in a sequential manner, to complete the booking?
No, you can directly jump to option d and still proceed ahead with the booking. However, it does not always assure a successful booking and there are chances of getting errors in case if conditions in the options a,b and c are not fulfilled.
4)Why does it happen that sometimes the availability call shows the accommodation as available while the proposal throws an error ‘Accommodation not available for given criteria'?
Such kind of issue are mostly faced due to one of the two reasons mentioned below,
a) Lag in refresh of availability index or/and price cache.
b) Subjects selected during the proposal call are not within the limits as setup in MXTS.
5)Why does it happen that sometimes a booking can be created successfully via MXTS but fails via API?
One of the reasons could be option 'a' from question 4 as mentioned earlier. However, there can also be a possibility related to permissions, GDPR level and access to AO/Locations given to API user restricting them to perform the required actions via API. One such action could be creating a booking.
6)Why do we need availability index and price cache?
The availability index and price cache are used by websites to display the availability and prices of accommodations. This serves as a middle layer between the database and the websites to fasten the process. Hence it is necessary that this information is inline with the actual information present in the database. To achieve the same there is refresh that takes place at regular intervals of time.
7)How frequently does the availability index and price cache refresh takes place?
For most of the clients the refresh takes place after every 2hrs. However, that does not mean that the recent changes done will always be available within the stipulated time of 2 hrs.
8)Why do some of the changes are not reflected in availability index and price cache even after more than 2 hrs?
Let’s say refresh is scheduled after every 2 hrs starting from 12:00 p.m....The changes are finished around 11:55 a.m. This would mean it will be picked up immediately in the cycle of 12 noon. The refresh process takes approx. 30 min but can take longer depending on how many changes are to be synched. Let’s assume it takes another 10 mins extra. So, by 12:40 the refresh process is completed, and you have the changes reflected just within 40 mins.
Other case could be that config changes were completed at 12:01 p.m. So, the refresh cycle of 12:00 p.m. has just started and these changes will not be considered...However in the next cycle of 2:00 p.m. this will get considered and 30-40 mins refresh process time again depending on amount of data. So the changes could be reflected around 2:40 p.m. even though the config changes were done around 12:01 p.m.
All the above is true only if the refresh process goes smoothly. In case if there are interruptions due to unseen circumstances like DB stability issues etc and process gets dropped then the process is not started again but will just get re-executed as per the next schedule. In such cases the delay can be even be upto 4hrs or more. But such cases are rare to occur.
9)Why are offers not shown on the landing page of client website?
Offers are taken into consideration for price cache and for displaying on landing page of website only when the toggle shown in the below screen is enabled in MXTS.
10)Why are the mandatory addon prices not added to the accommodation prices on the landing page of website?
The mandatory addon prices are added to the accommodation prices on the landing page of website only when the below mentioned toggle is enabled in MXTS.
11) Does each DC have a separate price cache?
As there are costs involved in setting up of price cache, from economical perspective price cache is built only for selected DC’s. The remaining DC’s generally follow one of the existing price cache. It depends on the clients request for the price cache.
12) What setup is needed to follow an existing price cache?
The DC of the existing price cache and the new DC should be selected in the same representation of the resource. Also, there should be rates available for the rate type of existing DC. The same rates will be followed for new DC.
13)Why are the amenities not shown on the website and also not returned in the API response?
Amenities are displayed on the website and included in the API response only when the toggle shown on the screen below is enabled in MXTS.
14) Why is accommodationtype/unit shown not applicable for a amenity even when the amenity is linked to accommodationtype/unit?
The endpoints used for fetching accommodationtypes/unit do not check if the amenity is applicable for accommodationtype/unit based on the principle of inheritance. The endpoints actually check the level at which the amenity is linked (self) and only such accommodationtypes/units are returned in the response which have the amenity linked at self level and not inherited from other sources.
15)Why does the website(index) not calculate or populate prices for certain DC?
There can be multiple or one of the below mentioned reasons:
a) check whether DC is marked as "has its own representation set" in Newyse. If it is marked as true, it is available in the index; if marked as false, then it is not available in the index.
b) Price cache is built only for specific DC’s and not for all. In such a case the DC of the existing price cache and the new DC should be selected in the same representation of the resource. Also, there should be rates available for the rate type of existing DC. The same rates will be followed for new DC.
16)Why are rates for some addons not calculated on the landing page of website?
We have two types of scripts that are used to populate and calculate prices in index for addons. The first one is a normal addon script (free)and is by default enabled for every concern. This script calculates the prices for all addons except the subject based addons. The second one is the ‘Additional cost script’ which is enabled only on the request of the client (chargeable).This script calculates the prices for all addons including the subject based addons.
Subject based addons : The addons having rates based on subjects OR/AND having subjects selected while linking them to accommodation are referred as subject based addons.