The following is a quick reference to the certification process. In this section we will give you all necessary information to complete the Certification process, which will ensure that your integration is ready to go Live.
Please consider, that carefully reading this section, and planning you implementation ahead, knowing what is going to be specifically requested by us, can lead to a much better experience and a sooner reaching of the goal: Being Live and ready to sell.
Please check the knowledge base, you can also contact us with any doubts or questions by email: integrations.btb@hotelbeds.com.
Before we start with the certification process we will need some information from you:
Find here full fillable template so you can complete it and send us once you are ready to start certification process.
| Operation | Implemented? (Y/N) | Comments |
| Search | YES / NO | Please detail here what type of searches filters you have implemented. |
| Availability | YES / NO | Please detail here what type of searches filters you have implemented. |
| Details | YES / NO | Indicate here whether you have implemented the "Simple" or "Full" |
| Booking confirm | YES / NO | Please indicate if you have implemented Pre-confirmation. |
| BookingDetail | YES / NO | This operation is Mandatory to retrieve a confirmed booking. |
| Booking List | YES / NO | Please indicate if you have implemented this operation. |
| BookingCancel | YES / NO | Please indicate if you have implemented this operation. Is highly advised that you allow your customers to cancel their bookings and if so this operation shall be implemented. |
| Cache API | YES / NO | If caching activities data, please let us know the flow used, see cache build recommedations |
| Multi-day tours | YES / NO | Please indicate if you have implemented multi-day tours UI. |
We are going to need the URL of your site, so we can review the way you have implemented the API and what information (as well as how it is shown) is being provide to your final customers. To do so, we will also need any possible credentials.
There are cases in which the business model is not aimed to provide a website for the final customer: it can be an intranet for a certain travel company, or a mobile app... In these cases, we will still need to review the technical implementation of the API and the info shown, and we will ask for alternative ways to do so:
The Certification process intention is to test and ensure that your team can get an additional external support in testing the functionality and implementation of the relevant and mandatory information.
The certification process will be adapted to the funnel agreed at the beginning of the process.
Why do we mandate for some information to be shown or provided to the customer? To avoid issues with the final consumer, or he/she is being misled by any incorrect information.
Our team is focused on ensuring that the final consumer is not going to have any problems.
This is ultimately converting to customer satisfaction and no issues.
Having said this, the tests that we do consider have two scenarios:
If you are storing data in your database, please let us know how you are updating it and how is your data caching flow working. What kind of data are you caching?
Please check cache build recommendations,
The testing is planned to be done considering the following test variables:
NOTE: If you are implementing availability using a Hotel ID please replace the test in Orlando using a Hotel ID (regardless of whether it is Hotelbeds, GIATA or TTI code).
If the implementation considers the Standard operations, the following tests will be performed (we will also test the functionality of barcodes at vouchers):
| Description | Description and steps | |
| Booking funnel buying one product and cancelling it | 1. Search for a list product in Barcelona. 2. Select one product and perform the Detail operation for the selected product (you can select the product as per your convenience. 3. Confirm the booking – Booking confirmation (here please use either the pre-confirm and/or re-confirm or confirm as per your implementation – In this case we will need to know the way you have decided for the implementation). 4. Generate the voucher. 5. Perform a booking detail to retrieve the information of the booking just confirmed. 6. Cancel the booking. |
|
| Booking funnel with sessions and languages. | 1. Search for product in London, for exampleE-U02-A0ABNO0084, but any activity that return any sessions and language (RS.activities/modalities/rates/rateDetails/sessions and RS.activities/modalities/rates/rateDetails/sessions/languages) will be fine. 2. Perform the detail of the product and select any rateDetails (each will have unique language and session). 3. Confirm the selected rateDetails ratekey (belonging to selected language and session.) 4. Generate the voucher including session and languages information. 5. Cancel the booking. |
|
| Booking funnel confirming a direct integration product (Those activities will return an PDF file for voucher) | Request for availability in New York (destination NYC) and search for activity E-U10-NYCEXPLORE (please contact if you don’t find availability) 1. Perform a detail of the product. 2. Confirm the booking. 3. For those cases you must take one of the PDF provided voucher “vouchers” array returned once confirmed. Please remember for those cases you must NOT generate any voucher, instead you must directly provide to final customers the PDF returned. 4. Cancel the booking |
|
| Booking funnel but adding a product that has questions in it, check questions functionality here | 1. Request availability for “Barcelona” (destination ”BCN”) see if "Hot Air Balloon Trip over Barcelona" . 2. Perform a details request for “E-E10-BALLONCOMP”. 3. Book the product a nswering the questions: for example: question": {"code": "HOTEL", "text": "Please advise the name of your hotel" "answer": "Hotel TEST" 4. Cancel the booking. Note you can also try with “E-E10-MORNALHGEN” in GRX, which will have more questions. |
As part of the integration process, there is some relevant information that must be provided to the client at some point during the booking funnel.
We don't want to restrict or constraint the way you implement your booking funnel at all, however, we must make sure that we do provide all relevant information to the end consumer.
We will not tell you how many pictures, for example, you must show, but we will require you to provide (if returned) the information on cancellation policies that apply to the product that is being booked.
You can find below the list of all the relevant information that is mandatory to provide to the customer.
The information to be provided to the client that is mandatory and as a minimum is the following:
| Area | API Attribute |
| Name of the Ticket / Activity | /activities/name |
| Description: You will see that in the Search descriptions may be cut. As a result, we strongly recommend that you concatenate a link to "More information" for the client to click there and go to the detail information of the product where the full description shall be used. We recommend adding the "More information" link in the red box shown in the example below | /activities/content/description |
| At least one picture of the Ticket/Activity | /activities/content/media/images[] |
| Price from for Adults | /activities.amountsFrom[] Note, only AD range or different CH ranges can be returned depending of the activity, see “E-E10-ACUARIOBCN” for multiple CH prices range. |
Regardless of whether the request is done for a full or simple detail, the following information is mandatory to be shown to the final consumer. These values in the response of the Detail must be provided to the end consumer at some point through the booking funnel.
| Area | API Attribute |
| Name of the Activity | /activities/name |
| Full description of the Activity | /activities/content/description |
| At least one picture of the Ticket/Activity | /activities/content/media/images[] |
| Destination | /activity/country/destinations/name |
| Features | /activity/content/featureGroups[] |
| Prices per Adult | /activity/amountsFrom[] |
| Price per Child | /activity/amountsFrom[] |
| Currency | /activity/currencyName |
| Operation Dates | /activity/operationDays |
| Modalities Names | /activity/modalities/name |
| Modality Price | /activity/modalities/amountsFrom[] |
| Comments (Contract_Remarks) | /activity/modalities/comments/text (where type = “CONTRACT_REMARKS”) |
| Total Amount for requested paxes | /activity/modalities/rates/rateDetails/paxAmounts[] |
| Question (if shown within the RS) | /activity/modalities/questions/text |
| Rate Information (if shown within the RS) | /activity/modalities/rates/name |
| /activity/modalities/rates/shortDescription | (for the moment only GENERIC are implemented) |
| Session (if shown within the RS) | Activity/modalities/rates/rateDetails/sessions/name |
| Language (if shown within the RS) | Activity/modalities/rates/rateDetails/languages/description |
| Routes | Activity/content/routes[] |
As per the previous analysis once a confirmation is done the following shall be shared as a minimum with the client:
Please make sure you take all the information form the booking response.
see also an visual example here.
Please make sure you understand how the voucher array works.
For normal activities, you must generate your own voucher with the information of the fields just provided, but in some cases, for example the activities with direct connection with supplier, the voucher will require some special format, as for example displaying a QR code or Barcode.
For those cases at the confirmation the “vouchers[]” won’t be null, if so you must provide the final customer with PDF format voucher and in any case generate your own.
In case of providing the incorrect voucher (the one generated by you) the final client won’t be able to access to the activity, as it needs to have a valid QR/Barcode or identification number.
The technical implementation review is very simple: we will review how you have configured your requests and how well you are using GZIP compression. Also, we will like to ensure that you are not sending multiple requests for one destination or, for example, to fulfil one destination product, that you are sending one request for each product in one destination.
The controls here are to ensure that you are performing and executing the requests in an expected manner.
In this step we will also review your website (if applicable) and understand if all the mandatory information is being provided and if not, we will come back to you for further information or to ask you to perform the relevant changes.
This is the last step and it will mean that you have been certified and approved to go live. At this time, you will be expecting to have a different Key and Secret code that you will need to change on your side as well as the URL to connect.
Information will be given to you upon confirmation. The last step once you are live is for us to review your LIVE process by executing one booking on your side and review the information that is given. The check will be only to ensure that the bookings is well created. We will do it on your behalf and in agreement with you.
You will then be ready and LIVE!
