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 careful reading of this section, planning your implementation ahead and knowledge about what exactly will be requested by us, can lead to a much better experience and a quicker reaching of the goal: Going Live and be ready to sell.

Nevertheless, in case of any doubts or questions please know you can contact us at

Our certification process is composed of 3 different areas:


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

  • Do you use a certified platform? Do you have a Platform Tag number?
  • List of operations that you have implemented
  • Website information: URL, User & Password (in case you use it)


Sometimes clients decide not to implement all operations. We want to know the scope of your development. Below you may find a template for you to fill in. The possible operations to be implemented are:






Please detail here what type of searches filters you have used. For example, if you have decided to implement filters for GPS and Destination. Detail all of the filters included.

Availability / Calendar


Please detail here what type of searches filters you have used. For example, if you have decided to implement filters for GPS and Destination. Detail all of the filters included.



Indicate here whether you have implemented the "Simple" or "Full" 

Booking Confirm


Please indicate if you have implemented the Confirmation as well as if you have implemented the Pre-Confirmation. Pre-Confirmation is typically used for clients that perform pre-payments to their clients and do not want to confirm before they have collected payment from the final consumer. This operation is Mandatory to complete a booking funnel.

Booking Detail


This operation is Mandatory to retrieve a confirmed booking.

Booking List


Please indicate if you have implemented this operation.




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. 



Please indicate and share with us if you have implemented a process to modify bookings.


We need the URL of your site in order to review the way you have implemented the API and what information is being provided to your final customers and how it is shown. To do so, we will also need any possible credentials.

  • URL:
  • User:
  • Pass:
  • Comments:

There are cases in which the business model is not aimed to provide a website for the final customer eg. intranet for a certain travel company, a mobile app etc. In these cases, we still need to review the technical implementation of the API and the info shown, and 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 misled by any incorrect information. Our team is focused to ensure that the final consumer is not going to have any problems. This ultimately converts 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 modifications and data caching request (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?


The testing is planned to be done considering the following test variables:

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

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


Booking funnel confirming two services

1.    Search for product in Berlin (if the destination is being sold if not we will select a different one)

2.    Perform the detail of one product (you can select a product randomly)

3.    Perform a detail of a second product (you can select a product randomly)

4.    Confirm the booking with both services – Booking confirmation (here please use either pre-confirm and re-confirm or confirm as per your implementation)

5.    Generate the voucher

6.    Perform a booking detail to retrieve the information of the booking

7.    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 Tenerife (destination TFS) and search for activity E-E10-LOROEXTRAS (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

1.    Request availability for “Krakow” (destination ”KRK”) see if AUSCHWITZ is present (if not please contact support in order to get a new activity)

2.    Perform a details request for “E-E10-AUSCHWITZ” (Auschwitz-Birkenau Memorial and Museum) that has questions.

3.    Book the product including 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.

NOTE: For each of these tests we will ask you to provide to us evidence of each operation including the Request, Response and generated voucher for all of them.

In addition to this, if you are doing and opting for the Enhanced operations which include Modifications, the following tests will be performed:

Test #


Description and steps

Test 5

Modification of product already booked (if modifications implemented)

1.    Obtain a product by searching for it in Orlando destination

2.    Perform a full detail of any product to get the full description of it

3.    Book and confirm the product

4.    Perform a second detail

5.    Confirm the modification of the product

·         See an example of booking modification for which the following was modified:

·         Client reference

·         Pax name

6.    Modality change (meaning that the service was kept the same, but the modality first booked was replaced by a new modality for the same service)

7.    You can use a combination of pax as per your own wish. Only one combination for this test will be enough


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.

Below you may find 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:


API Attribute

Name of the Ticket / Activity


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


At least one picture of the ticket


Price from for Adults


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.


API Attribute

Name of the Activity


Full description of the Activity


At least one picture of the Ticket/Activity






Price per Adult


Price per Child




Operation Dates


Modalities Information


Modality Price


Comments (Contract_Remarks)


/activity.modalities.comments.text (where type = “CONTRACT_REMARKS”)

Total Amount for requested paxes


Question (if shown within the RS)


Rate Information (if shown within the RS)



(for the moment only GENERIC are implemented)

Session (if shown within the RS)

(for the moment NOT implemented, soon will be)

Language (if shown within the RS)


(for the moment NOT implemented, soon will be)

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.

  • Reference Number | Returned in “/booking.reference”.
  • Full name of the Ticket/Activity | Returned in ”/”.
  • Date when booking was confirmed | Returned in “/booking.creationDate”.
  • 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”.
  • Session Selected (if shown within RS) | Returned in “/”.
  • Language Selected (if shown within RS) | Returned in “/”.
  • Pickup point (only for Excursions, Not Implemented for the moment) | Returned in “/booking.activities.pickup[]”.
  • 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!