Introduction#
Amadeus Discover is a B2B platform that digitalizes the distribution of Destination Experiences. By using the our REST-based API, you can push and pull data to and from Discover, and integrate it with other systems. Feel free to contact us if something is not working properly.
This API implement and enhance the OCTo Specification, the most popular standard API specification for experiences tourism market and used by most of industry actors.
Fig. 1 Global view of Amadeus Discover services#
This API (Application Programming Interface) conforms to the constraints of REST architectural style and allows for interaction with RESTful web services and uses JSON data as payloads. The access to the API is protected and controlled using temporary API access tokens. The authentication and authorization flows from application point of view are based on the OAuth 2.0 specification.
The following sections capture the API in detail, by describing all the exposed endpoints with self-explanatory examples.
Interoperability#
The Catalog Management API is targeting any external aggregator (BMS) willing to push suppliers and products to Amadeus Discover platform. It is shaped to guarantee the high-level quality of products which will then be exposed to the various channels and applications accessing the Amadeus Discover catalog.
Fig. 2 Flow chart of the available workflow for a BMS to transmit data to Amadeus Discover backends#
Data are pushed in Amadeus Discover native data model, which corresponds to an extension of the OCTo model.
Process from Start to Production#
Fig. 3 Process from start to sandbox to production#
Amadeus Discover Content Partners can push and manage catalogue of activities to Amadeus Discover Platform. These activities will then be visible to Amadeus Discover applications and API users, and proposed to travellers so they can perform bookings. In order to boost visibility of your catalogue of activities, and ensure a high level of Data Quality for travellers, Amadeus Discover recommends to follow the guidelines presented in this documentation.
APPLY Get in touch with Amadeus Discover team to apply for Content Partner API access. You will be contacted to establish the Content Partner API contract and get access to our Sandbox environment.
- For account registration and access our Sandbox environment, please contact us at (either):
SANDBOX This is where our partners freely test our API and calibrate for integration.
PRODUCTION This is where our partners go live on our production database and get their products booked.
Data model#
There are two main key concepts used in the API: Supplier and Product objects. They are compliant with the OCTo standard.
Supplier: Entity that provides one or several product(s) for the final client (traveller). Each supplier is identified on Amadeus Discover side by a unique ID. A supplier can have an unlimited number of products. Information supported for the supplier are described just below :
Geolocation: Data fields about geographical location of the supplier. This information may possibly appear as duplicates : in that case, supplier and product geolocation aren’t the same place.
Country: All the information about the supplier country (e.g. FR).
SupplierContact: Data fields containing the supplier contact information (e.g. email, address).
Product: Activity provided by a supplier to a traveller. Each product is identified on Amadeus Discover side by a unique ID. The unique ID is also used to link a product to a supplier. There cannot be a product without a supplier. All the suppliers and products are defined and linked together using their unique IDs. Information supported for the products are described just below:
ProductOption: All the different options that can be proposed for a product.
Unit: It can be an “ADULT”, a “ CHILD “, an “ INFANT “, “ YOUTH “, “ STUDENT “, “ SENIOR “, “ TRAVELLER “,” RESOURCE “, and “ OTHER “.
Category: The type of product (e.g. Kayak….).
Country: All the information about the product country (e.g. FR); A supplier can own products in various countries.
Duration: The duration of the product (e.g. 2 hours, 2 days…).
Capability: To provide better support for features that may not be required by all products or bookings, the API is built to support capabilities. These capabilities can be specific to a particular reseller or booking platform, but there will also be adopted standards for capabilities that are very common (e.g. pricing, booking questions, etc.) to provide a standard interface for the most common additional features that are not covered in the API.
Glossary#
- Amadeus Discover
The name of this project.
- API
Application Programming Interface. This is a technical way to make two systems (e.g. web services) communicate together.
- BMS
Booking Management System. They are aggregators of suppliers and their products. The booking of a product is done by their platforms.
- Content Partner
Business entity that provides one or multiple products. A Content Partner can be a BMS, a content aggregator of different suppliers or directly a supplier owning multiple products.
- OCTo
Open Connectivity for Tourism, which is an industry initiative to develop and foster the use of standard API (and others) specifications to help solve long standing issues in the in-destination activities industry. Official OCTo website
- Product
Activity provided by a supplier.
- Swagger
Suite of API developer tools, including specification for defining REST APIs. The Swagger UI document the list of resources available in the REST API and the operations that can be called on these resources.
- Token
A token is a unique and temporary security element for authenticating users (a cryptographic sequence which looks like a random sequence of characters).