Certification process

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:

Before starting

Before we start with the certification process we will need some information from you:

  • Integration expectative, basic business model, big picture.
  • Are you making a direct integration or using an IT developer / platform (in case of using a IT developer / platform, please confirm)
  • List of operations that you have implemented
  • Development information: URL, User & Password (if accessible)
  • Commercial agreement with Hotelbeds is needed in order to complete the certification process and obtain LIVE credentials, buy we’ll offer development support. (Sign up here for commercial assistance)

Find here full fillable template so you can complete it and send us once you are ready to start certification process.

Confirm us the implemented operations:

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.

  • URL:
  • User:
  • Pass:
  • Api-key:
  • Comments:

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:

  • Screenshots demonstrating each relevant step of a booking funnel, or
  • A video capture of a complete booking funnel, or
  • Maybe even a web meeting sharing screen and performing a full booking funnel.


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:

  • Standard operations: in case the implementation only considered the following operations Search, Detail, Booking Confirm, Booking Detail, Booking List, and Cancel Request.

  • Enhance operations: in case the implementation also added features such as data caching request (portfolio, availability and content calls)


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:

  • Destinations to be used
    • Barcelona
    • Berlin
    • Tenerife
    • Krakow
    • Orlando
    • New York

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).

  • Passenger´s distributions to be used
    • 2 adults - 2 children (1 year old and 17 years old)

If the implementation considers the Standard operations, the following tests will be performed (we will also test the functionality of barcodes at vouchers):

Test #
Description Description and steps
Test 1
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.

Test 2
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.

Test 3
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

Test 4
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.

Search Page

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.

Details Page

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[]

Confirmation Page

As per the previous analysis once a confirmation is done the following shall be shared as a minimum with the client:

  • Name of the Activity
  • Date of Service Booked (@from @to values for multiple days activities)
  • Modality, (Rate and/or Session if returned in detailRS)
  • Price Paid
  • Currency
  • Pax Distribution
  • Children Ages
  • Question/Answer (if shown within the logs): If the question is required (activity/modalities/question/@required) then this question is mandatory to be input in the Confirmation operation request.
  • Comments (Contract_Remarks)
  • Cancellation Policies information, (if returned in detailRS)

Voucher information

Please make sure you take all the information form the booking response.
see also an visual example here.

  • Reference Number | Returned in “/booking.reference”.
  • Full name of the Ticket/Activity | Returned in ”/”.
  • Date when booking was confirmed | Returned in “/booking.creationDate” (Recommended).
  • Lead Pax Name | Returned in “/holder”.
  • From and To for the Ticket/Activity | Returned in FROM “booking.activities.dateFrom” TO “/booking.activities.dateTo”.
  • Modality Name | Returned in “/”.
  • Pax Distribution | Returned in “/booking.activities.paxes”.
  • Children Ages (Children ages) | if (/booking.activities.paxes[].age <18) display age in voucher.
  • Destination | Returned in “/”.
  • Remarks (Contract_Remarks): essentially provides the redeem info for the client to know what to do to obtain the tickets | Returned in “/booking.activities.comments[].text”(WHERE TYPE ="CONTRACT_REMARKS")”.
  • Supplier Info (Name, Address and Reference of Supplier if shown in the logs) | Returned in ”booking.activities.providerInformation”.
  • “Bookable and Payable by” information | Returned in “/booking.activities.supplier” Bookable and payable thru “/” with VAT “/booking.activities.supplier.vatNumber”.
  • Language Selected (if shown within RS) | Returned in “/booking.activities.modality.rates.rateDetails.languages.code”.
  • Barcode/QR code | In case of returning the “/booking.activities.vouchers[]” != null.


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.

  • IF “/booking.activities.vouchers[]” = null -> Generate your own voucher.
  • IF “/booking.activities.vouchers[]” != null -> Provide one of the returned in PDF format to final client and do NOT generate your own.


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!