To use ContentAPI to its maximum effectiveness we encourage its users to set up a batch process to retrieve the info from them on a periodic basis, and a database on their side to store the retrieved information and be able to use it when needed. The design of the batch and the database is up to you since not all users have the same needs.
ContentAPI calls and examples are included in APItude's Postman collection, so feel free to test the different request operations of the ContentAPI to familiarize yourself with them before starting your integration with ContentAPI.
IMPORTANT NOTE: By no means should the ContentAPI be used to retrieve the static information in real-time. This could result in the blocking of credentials.
One of the main objectives when integrating the ContentAPI is to retrieve the information of the hotels. It is a necessity not just to have the hotel code list to request availability by hotel codes, but also to have the static information of the hotels and be able to show it in your booking process when needed. The best way to retrieve such information is to do it with the Hotels operation, which allows retrieving paged results up to 1000 hotels per request.
As the current Hotelbeds accommodation portfolio is comprised of 173000 hotels approximately, for the initial load of the database 173 requests would be needed to get all the information, defining the first and last hotel in each request in the from and to parameters:
And so on...
Additionally, to load the database with the rest of operations to have all the descriptions of the different elements returned in the Hotels operation (segments descriptions, facilities descriptions, destinations, ...) the following petitions will be needed in the same way as the Hotels operation request:
The following operations are not considered mandatory, but we encourage its implementation as well:
In all, the total amount of petitions would be: 173 + 21 + 1 (currencies) + 2 (terminals) + 100 (rate comments) = 297 petitions to have the database loaded with the initial information. With the 4 QPS (Queries Per Second) limit that you will have in the Production plan, this means that in 75 seconds you would have sent all the needed petitions to obtain the initial load of your database. (Not taking into account the needed time to process all the responses and load the info in your database).
This would be just the petitions for one language, so you would need (as the descriptions text fields are language dependant) to repeat this process for every language you wish to implement. You can check which ones are accepted in APItude via the Languages operation.
Once you have the initial load you would only have to do one request (we recommend on a daily basis) using the parameter lastUpdateTime to get the differential changes and updates in our static information. For example:
In this way, you would receive only what has been updated since the date you indicate if you do it daily and we have an average of 3000 hotels updated you would only need 3 petitions to have all the updated hotels.
