Guidelines

Redirection flow / Booking Flow

Amadeus Discover Quick Connect is designed for various actors in the travel industry—such as travel agencies, airlines, and hotels—or any entity aiming to enhance their offerings with destination activities for travelers.

The API supports two distinct distribution flows: Redirection Flow and Booking Flow.

The Redirection Flow involves redirecting travelers to an external booking URL, where they complete the booking on an external system like Viator or Holibob. In this flow, the external booking system manages the entire booking process, including payment, voucher issuance, and after-sales support. At the end of each month, you will receive a booking report, and commissions are paid after the activity has taken place.

The Booking Flow allows you to integrate the booking process directly into your UI or application by using various API endpoints (such as checking availability, selecting options, describing participants, confirming bookings, and sending vouchers). In this scenario, you handle the payment process and maintain full control over the booking, receiving live booking references and details. You are responsible for all traveler-facing activities, including sending vouchers, managing booking references, and handling cancellations.

Flow comparison

	Redirection Flow	Booking Flow
Traveler flow for booking	Traveler is redirected to an external booking link to book the activity.	Booking steps are triggered from your system. Travelers stay in your ecosystem for the full booking flow.
Merchant of records	External Booking System (ex Viator, Holibob)	Your company
Level of access	Available with basic Quick Connect account	Requires specific level of access
Eligible content	100% content	30% content

Starting with the Redirection Flow provides a rapid time to market, enabling you to quickly validate the value of offering destination activities to your customers. As your integration matures and the value proposition is proven, the solution can easily evolve to incorporate the Booking Flow. This progression allows you to start with a simpler setup and gradually move towards a more integrated and controlled booking process, enhancing the customer experience and retaining more control over transactions.

To begin your integration, it is crucial to determine whether you intend to use the Redirection Flow or the Booking Flow. This decision will guide the setup process and ensure that you implement the API in a manner that aligns with your business needs and capabilities.

FIND / SHARE / BOOK

The flow with Amadeus Discover API can be split in 3 steps :

1. FIND relevant products

2. SHARE products with travelers

3. BOOK products

FIND relevant products

Amadeus Discover API proposes different endpoints, covering diverse use cases to find the most relevant products in your context. These endpoints return a list of products corresponding to the search criteria, including all details you might need about the products to expose them to travelers (title, description, images, booking URL, duration, geolocation, taxonomy, opening hours, cancellation policy, min / max price, additional information, booking engine…)

• The Recommendation Engine endpoint allows to obtain relevant products based on a context. Depending on trip context (leisure, business, staycation), traveler type (solo, family, couple, group), activity risk level (safe, moderate, dangerous) and interests, the endpoint will return different products, with the highest expected conversion rate.

• The Top Products endpoint allows to obtain a list of the best products per destination, without additional context. The destination an be specified via iata code, cohordinates or city name.

SHARE products with travelers

In order to expose the products that have been identified to the Traveler, two options are available:

• Expose the products in your own UI. In the search results, all required elements are available to expose the products in your own UI. Title, Description, Images, Opening Hours, Cancellation policy, Ratings, and many more elements can be used to build products overview and detail pages in your own UI, ensuring an integrated user experience.

• Use Amadeus Discover White Label. Amadeus Discover has developed a white label Traveler facing application, that can be used to expose products to traveler with minimal integration efforts. Standalone links can be generated to be shared to travelers via email or QR codes. The application is also available as widget to be integrated directly in your UI. Amadeus Discover Traveler Application has been designed with a User Experience focus to optimize the travelers experience and boost bookings. See an example.

BOOK products

The API supports two distinct distribution flows: Redirection flow / Booking Flow.

• To implement the Redirection Flow, you just need to retrieve from the products response the parameter “booking URL” in the language you are targeting and implement the redirection to the link in your own UI. The booking URL includes a parameter to identify that the bookings are generated from your traffic. Note that if you are using Amadeus Discover Traveler Application, the links are already implemented in the UI with the same tracking mechanism.

• To implement the Booking Flow, you will need to implement the Booking Flow endpoints and orchestrate the flow in your UI (Booking flow).

Catalog ingestion

What is Catalog Ingestion?

Catalog ingestion refers to the process of retrieving the full set or a subset of products available in the Amadeus Discover catalog through dedicated API endpoints. These endpoints return the complete product data, including descriptions, images, geolocation, operational details, and booking URLs. The objective is not to perform relevance based search (as done with the recommendation endpoints) but rather to import a large, exhaustive dataset that can be stored and reused in your own system. Because the product catalog evolves continuously, catalog ingestion typically requires regular synchronization to keep your local copy accurate and up to date (e.g., daily refresh).

In which cases should catalog ingestion be used ?

Depending on your use case, you may choose to rely either on live Discover API calls or on an internal process based on catalog ingestion. Live calls are ideal when you need up to date, dynamic information and when product discovery must react to a traveler’s real time context, typically by using Recommendation Engine endpoints. In contrast, catalog ingestion becomes the preferred option when your platform aims to minimize external dependencies, process or enrich data internally, or operate features that require local indexing, such as home-made recommendation engines. By maintaining your own internal version of the catalog, you gain full control over performance, data enrichment, and curation workflows, while still being able to periodically synchronize updates through the dedicated ingestion endpoints.

Amadeus Discover Catalog Ingestion Methods

Catalog ingestion is performed in two steps, combining a full load followed by incremental updates.

Step 1 — Initial ingestion

Use the Get Active Activities endpoint to retrieve all active products in the catalog. This initial call returns the full set of product details (titles, descriptions, images, geolocation, etc.). NB : Store the timestamp of this first ingestion, as it will be needed for incremental updates.

Step 2 — Periodic Updates

At a regular cadence (commonly once per day):

1. Call Get Active Activities with a “since last sync” timestamp This returns products that were added or updated since your last ingestion.

2. Call Get Inactive Activities This returns products that were removed from the catalog.

This incremental approach allows you to keep your local copy fully synchronized without re ingesting the entire catalog each time. NB : After each sync, store the latest timestamp, which you will reuse for the next synchronization cycle.

Ingestion cursor

The API uses an import cursor for pagination. Both endpoints support the same process to retrieve the catalog in batches. When you call one endpoint for the first time, you can specify an optional modifiedSince date to retrieve the products that have been added/updated or removed since this date. The response will include an importCursor, which includes an obfuscated timestamp that indicates the point in time up to which the products have been retrieved. For the next page, you can use this import cursor to retrieve only the products that have been added/updated or removed since the last synchronization.

Ingestion endpoints

The endpoints available for the catalog ingestion are:

• Get Active Activities Endpoint

• Get Inactive Activities Endpoint

Example workflow

First of all, you need to define the scope of your ingestion:

• Decide the optional filters to use in the ingestion: country and booking engine list. Use these same filters for all requests.

1. Initial ingestion:

   • Call the Get Active Activities endpoint with NO modifiedSince date to retrieve the activities that are active now. Keep the importCursor returned in the response for the next page.

   • Call the Get Active Activities endpoint with NO modifiedSince date and the importCursor from previous call until the importCursor returned in the response is empty.

   • Store the date of the last request. It will be needed for the periodic updates.

2. Periodic updates:

   • Call the Get Active Activities endpoint with modifiedSince date from last catalog ingestion or update to retrieve the activities that have been created or updated since that modifiedSince date. Keep the importCursor returned in the response for the next page.

   • Call the Get Active Activities endpoint with modifiedSince date and the importCursor from previous call until the importCursor returned in the response is empty.

   • Call the Get Inactive Activities endpoint with modifiedSince date from last catalog ingestion or update to retrieve the activities that have been removed since that modifiedSince date. Keep the importCursor returned in the response for the next page.

   • Call the Get Inactive Activities endpoint with modifiedSince date and the importCursor from previous call until the importCursor returned in the response is empty.

   • Store the date of the last request. It will be needed for the next periodic update.