.png)
Amadeus Integration Guide
Integrate Amadeus travel search, pricing, booking, hotel, location, and recommendation APIs with enterprise applications through REST-based workflows.
Amadeus integration options at a glance
Amadeus for Developers and Self-Service APIs primarily use JSON-based REST APIs for flight search, offer pricing, flight orders, hotel offers, locations, airports, destinations, and travel recommendations. Authentication uses OAuth 2.0 client credentials with an Amadeus API key and secret exchanged for a bearer token. General-purpose webhooks, file transfers, database access, and GraphQL APIs were not confirmed for the reviewed products. Martini can consume Amadeus REST endpoints, cache and renew tokens, orchestrate search and booking workflows, map travel payloads into enterprise models, expose a controlled API façade, and run scheduled reconciliation where event notifications are unavailable.
| Integration point | Supported by Amadeus? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Amadeus REST APIs support flight and hotel search, offer pricing, flight orders, locations, destinations, airports, and travel recommendations using resource-oriented JSON requests and responses. | Martini can consume Amadeus REST APIs, generate reusable API integration assets, map JSON payloads, orchestrate multi-step workflows, and expose REST APIs for downstream applications. |
| GraphQL APIs | Not confirmed | No official GraphQL API was identified in the reviewed Amadeus for Developers documentation. | Martini can consume GraphQL APIs generally, but an Amadeus GraphQL interface should not be assumed; use the confirmed REST APIs unless a product-specific interface is verified. |
| SOAP APIs | Legacy | Amadeus has historical and enterprise web-service products, but the reviewed Self-Service documentation centers on REST and does not confirm SOAP for new integrations. | Martini can consume SOAP services where a specific Amadeus product and WSDL are confirmed, but SOAP should be treated as product-specific and legacy for this scope. |
| Webhooks / outbound callbacks | Not confirmed | A general-purpose Amadeus Self-Service webhook or callback facility for booking, offer, or reservation changes was not confirmed. | Martini can receive webhooks from systems that provide them, but Amadeus change detection should normally use scheduled retrieval or reconciliation unless a product-specific notification mechanism is verified. |
| Bulk / async / batch APIs | Limited | Some Amadeus APIs may have different response or processing patterns, but a universal bulk or batch mechanism for all travel objects was not confirmed. | Martini can orchestrate bounded, scheduled, or asynchronous workflows and handle result limits, but the implementation must follow the specific Amadeus API's documented behavior. |
| File / attachment APIs | No | No general file import, export, or attachment API was identified for the core Amadeus Self-Service APIs; travel data is exchanged through REST payloads. | Martini supports file processing generally, but a file-based Amadeus integration should not be designed without a separate confirmed Amadeus product interface. |
| Database / analytics access | No | Amadeus does not expose a customer-facing relational database interface for ordinary Self-Service integrations. | Martini can write normalized Amadeus data to enterprise databases or analytics platforms through supported interfaces, but it should consume Amadeus through APIs rather than direct database access. |
| Authentication | Yes | Amadeus Self-Service APIs use OAuth 2.0 client credentials with an API key and secret to obtain a time-limited bearer access token. Sandbox and production use separate credentials and base URLs. | Martini can store credentials in secure environment configuration, obtain and cache bearer tokens, add authorization headers, renew tokens near expiration, and isolate sandbox from production settings. |
How Amadeus exposes data and business events
Amadeus REST APIs
REST is the primary Amadeus Self-Service integration mechanism. The APIs use resource-oriented requests and generally JSON responses for flight and hotel search, pricing, booking, location, destination, airport, and recommendation operations.
Martini implementation pattern
Martini implementation pattern: a Martini API or workflow receives a request, obtains or reuses an Amadeus OAuth access token, calls one or more REST endpoints, validates the response, maps the result into an internal model, and returns or persists the outcome. Multi-step booking flows should preserve transaction state and distinguish safe read retries from unsafe booking retries.
Implementation sequence
OAuth 2.0 authentication
Amadeus Self-Service APIs authenticate through OAuth 2.0 client credentials. An API key and secret are exchanged at the Amadeus token endpoint for a time-limited bearer access token, with distinct sandbox and production credentials.
Martini implementation pattern
Martini implementation pattern: store the Amadeus key and secret in secure environment configuration, request a token only when needed, cache it until near expiration, attach the bearer token to API calls, and renew it after expiration. Booking requests require stricter retry decisions than read-only searches.
Implementation sequence
Scheduled reconciliation
A general-purpose Amadeus webhook or outbound callback mechanism was not confirmed. Changes after an initial booking may therefore require controlled scheduled retrieval where the relevant Amadeus product supports order or reservation lookup.
Martini implementation pattern
Martini implementation pattern: schedule a workflow to retrieve eligible Flight Orders or other supported resources, use an order identifier, timestamp, cursor, or documented change-detection field, compare the result with the stored enterprise state, and update downstream systems without assuming that every Amadeus object emits events.
Implementation sequence
Common Amadeus integration patterns
Pattern 1: Orchestrate travel search through an API façade
When to use this pattern
Use this pattern when multiple travel portals or enterprise applications need a consistent search interface while Amadeus-specific API details, policy rules, and response normalization remain centralized.
Integration direction
Example Mapping
| Amadeus Field | Canonical Field | Target Field |
|---|---|---|
| Flight Offers.itineraries | journey.segments | portal.results[].segments |
| price.total | totalAmount | results[].price.amount |
| price.currency | currencyCode | results[].price.currency |
| travelerPricings | fareConditions | results[].fareRules |
Martini implementation pattern
Expose a Martini REST API that validates search criteria, obtains a cached Amadeus token, calls flight or hotel search endpoints, normalizes itineraries, currencies, rooms, and cancellation details, and applies enterprise rules such as preferred airlines or fare thresholds. Return a stable internal response model and classify rate-limit or temporary failures for controlled retry.
Martini capabilities used
- APIs
- workflows
- API consumption
- data mapping
- business rules
- error handling
Pattern 2: Reprice and create a flight order
When to use this pattern
Use this pattern when a booking application must safely coordinate offer selection, current pricing, traveler validation, and Flight Order creation while limiting duplicate-booking risk.
Integration direction
Example Mapping
| Amadeus Field | Canonical Field | Target Field |
|---|---|---|
| Flight Offers.id | selectedOfferId | flight-offer.id |
| Flight Offers.itineraries | journeySegments | flight-order.itineraries |
| traveler data | travelerProfiles | flight-order.travelers |
| Flight Orders.id | reservationReference | booking.reservationId |
Martini implementation pattern
A Martini workflow receives the selected Flight Offer, requests current pricing through the Flight Offers Price operation, validates traveler and policy data, and creates the Flight Order only when the price and conditions remain acceptable. Persist the business transaction identifier and source response before updating downstream systems; do not automatically replay an uncertain booking request without a safe reconciliation method.
Martini capabilities used
- workflows
- API consumption
- data mapping
- validation
- business rules
- error handling
- monitoring
Pattern 3: Synchronize flight and hotel reservations
When to use this pattern
Use this pattern when corporate travel, customer service, expense, or finance applications need normalized booking and itinerary information from Amadeus.
Integration direction
Example Mapping
| Amadeus Field | Canonical Field | Target Field |
|---|---|---|
| Flight Orders.id | reservationId | Salesforce booking reference |
| Flight Orders.travelers | travelerContacts | Salesforce contacts |
| Hotel Offers.hotel | property | Salesforce hotel property |
| Hotel Offers.price | bookingAmount | Salesforce travel amount |
Martini implementation pattern
Use a scheduled or request-driven Martini workflow to retrieve supported Amadeus reservation data, normalize flight and hotel structures, resolve traveler or customer identifiers, and update Salesforce or another target. Apply idempotency using source order identifiers, minimize sensitive traveler data in logs, and route unknown outcomes to reconciliation rather than creating duplicate downstream bookings.
Martini capabilities used
- scheduled workflows
- API consumption
- data mapping
- data transformation
- business rules
- error handling
Pattern 4: Enrich travel requests with locations and recommendations
When to use this pattern
Use this pattern when travel requests, itinerary records, or customer experiences require airport, city, destination, or recommendation data from Amadeus.
Integration direction
Example Mapping
| Amadeus Field | Canonical Field | Target Field |
|---|---|---|
| request.destinationCode | destinationCode | Amadeus location query |
| Locations.name | destinationName | travel request.destinationName |
| Locations.iataCode | airportCode | itinerary.airportCode |
| Travel Recommendations.results | recommendedDestinations | travel planning suggestions |
Martini implementation pattern
Martini receives or schedules travel requests, resolves locations or recommendations through Amadeus REST APIs, caches stable reference information where permitted, applies destination and policy rules, and returns enriched data to the originating application. Validation failures and unavailable recommendations should be handled as recoverable outcomes without blocking unrelated workflow processing.
Martini capabilities used
- workflows
- API consumption
- data mapping
- caching strategy
- business rules
- error handling
Applications commonly integrated with Amadeus
Amadeus data and booking workflows can be connected to named enterprise applications through Martini when travel search, reservations, traveler context, approvals, finance, or service operations need to be coordinated. The exact direction and supported operations depend on the Amadeus product, the target application's APIs, and the business process.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Store traveler profiles, corporate travel requests, booking references, and customer-service context alongside Amadeus reservation data. | Salesforce → Martini → Amadeus | Expose a Martini REST API for search or booking requests, call the relevant Amadeus REST APIs, normalize Flight Orders or Hotel Offers, and update Salesforce through its APIs with transaction identifiers and controlled retry handling. |
| ServiceNow | Create travel-related requests, approvals, incidents, or support cases using flight and hotel booking information. | Amadeus → Martini → ServiceNow | Use scheduled or request-driven Martini workflows to retrieve Amadeus booking information, apply business rules, map reservation data to ServiceNow records, and route failures for reconciliation rather than duplicating bookings. |
| SAP Concur | Reconcile travel reservations, traveler information, expense records, and itinerary data. | Amadeus → Martini → SAP Concur | Retrieve supported Amadeus reservation or itinerary data, map traveler and cost information to the SAP Concur model, preserve source identifiers, and use scheduled synchronization with duplicate detection. |
| Microsoft Dynamics 365 | Associate travel bookings and customer interactions with accounts, contacts, and service processes. | Microsoft Dynamics 365 → Martini → Amadeus | Receive a travel request through a Martini API or workflow, validate the request, orchestrate Amadeus search or booking calls, and write normalized itinerary and confirmation data back to Dynamics 365. |
| NetSuite | Transfer travel-related customer, supplier, invoice, or cost information into financial and operational processes. | Amadeus → Martini → NetSuite | Map Amadeus booking and cost data to NetSuite objects, apply accounting and duplicate-prevention rules, and persist the Amadeus order identifier for reconciliation and safe retry decisions. |
| Workday | Support employee travel processes by connecting worker, cost-center, approval, and travel-request data with booking workflows. | Workday → Martini → Amadeus | Use Workday data as controlled traveler and policy context, invoke Amadeus REST operations through Martini, and return booking outcomes while minimizing sensitive personal data in logs and payloads. |
| Jira | Create operational or support tickets when booking, pricing, or travel synchronization requires investigation. | Amadeus → Martini → Jira | Classify Amadeus errors and uncertain outcomes in Martini, attach non-sensitive transaction context, and create Jira issues for manual reconciliation or implementation follow-up. |
| Stripe | Coordinate payment or billing workflows associated with travel transactions where payment is managed separately from the Amadeus booking operation. | Booking application → Martini → Stripe | Orchestrate payment and Amadeus calls with explicit business transaction state, avoid replaying uncertain booking operations, and reconcile payment and reservation outcomes before finalizing downstream status. |
How to build a Amadeus integration in Martini
Objective
Establish separate sandbox and production connections to Amadeus using OAuth 2.0 client credentials and environment-specific configuration.
Instructions in Martini
- Store the Amadeus API key and secret in secure environment configuration.
- Configure separate Amadeus base URLs, credentials, quotas, and test data for sandbox and production.
- Implement token acquisition and reuse rather than requesting a token for every API call.
Objective
Select an API request or schedule based on whether the integration handles an interactive search or booking flow, or a recurring reconciliation process.
Instructions in Martini
- Use a Martini REST API for synchronous search, pricing, or booking requests.
- Use a scheduler for supported reservation retrieval, enrichment, or reconciliation workflows.
- Do not assume that Amadeus will push general-purpose booking or offer events.
Objective
Call the appropriate Amadeus REST operation and manage token renewal, response limits, and transient failures.
Instructions in Martini
- Retrieve Flight Offers, Flight Offers Price, Flight Orders, Hotel Offers, Locations, or Travel Recommendations as required.
- Review the specific endpoint's result limits, pagination behavior, and product eligibility.
- Apply bounded concurrency and backoff for rate-limit or temporary availability responses.
Objective
Coordinate dependent calls and preserve business transaction state across search, repricing, booking, and downstream synchronization.
Instructions in Martini
- Sequence offer search, pricing, validation, and booking operations where applicable.
- Persist source identifiers, request state, and transaction context before updating downstream systems.
- Separate safe read retries from unsafe booking retries and route uncertain outcomes to reconciliation.
Objective
Convert Amadeus JSON payloads into stable internal and target application models while handling optional fields and travel-specific structures.
Instructions in Martini
- Map itinerary segments, currencies, fare conditions, traveler data, rooms, rates, cancellation details, and reservation identifiers.
- Normalize dates, amounts, codes, and location data for the target application.
- Preserve source identifiers and avoid logging unnecessary personal or payment-related data.
Objective
Enforce travel, booking, privacy, and operational policies before committing results to downstream systems.
Instructions in Martini
- Validate traveler and search inputs before calling Amadeus.
- Apply approved-airline, destination, fare, price, or booking-policy rules where required.
- Revalidate offer price and availability immediately before booking when the API requires it.
Common Amadeus data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Flight Offers | Represent available flight itineraries, segments, pricing, fare details, and traveler-related conditions during search. | Travel portals, Salesforce, SAP Concur, Microsoft Dynamics 365, data platforms | Martini retrieves and validates the offer payload, normalizes segments, currencies, and fare data, applies policy rules, and maps the result to the target application's journey model. |
| Flight Offers Price | Represent the priced or confirmed version of a flight offer before booking. | Booking applications, travel management systems, payment orchestration services | Martini invokes the pricing operation immediately before booking, compares the returned price and conditions with the selected offer, and prevents booking when business validation fails. |
| Flight Orders | Represent booked flight reservations created from priced offers and traveler information. | Salesforce, SAP Concur, ServiceNow, NetSuite, customer portals | Martini stores the Amadeus order identifier, maps traveler and itinerary details, applies duplicate and reconciliation controls, and avoids unsafe automatic replay of uncertain booking requests. |
| Hotel Offers | Represent hotel availability and rate offers, including room, rate, price, and cancellation information. | Booking portals, SAP Concur, Salesforce, reservation and notification systems | Martini transforms room and cancellation data into an accommodation model, rechecks price and availability where required, and passes confirmed details to downstream systems. |
| Locations | Represent airports, cities, points of interest, and other travel-related geographical locations. | Travel portals, CRM systems, data warehouses, policy services | Martini can use location data to resolve codes, enrich itineraries, validate destinations, cache stable reference data where permitted, and map location attributes to internal models. |
| Travel Recommendations | Provide destination or travel recommendation results based on origin, dates, or other search criteria. | Travel portals, personalization services, marketing and planning applications | Martini calls the recommendation API, applies destination or policy filters, normalizes the result, and exposes it through an internal API or sends it to a downstream application. |
Authentication and security considerations
OAuth 2.0 client credentials
Amadeus Self-Service APIs use an API key and API secret to obtain a time-limited bearer access token. Martini can manage token acquisition and renewal in workflows while sending the bearer token on Amadeus API requests.
Environment separation
Keep sandbox and production base URLs, credentials, quotas, and test data separate. Store credentials in secure environment configuration rather than workflow payloads or source code.
Traveler data protection
Traveler information can include personal and identity-related data. Minimize data passed between systems, protect sensitive payloads, and avoid writing unnecessary personal information to logs.
Operational considerations for Amadeus integrations
Rate limits and quotas
Amadeus plans impose usage limits. Cache access tokens, use bounded concurrency, apply backoff for throttling, and monitor quota consumption and error rates.
Offers and booking safety
Flight and hotel offers can expire or change price. Revalidate offers before booking, persist transaction identifiers, and do not automatically replay an uncertain booking request without a safe reconciliation method.
Pagination and result limits
Review each API's result-size, pagination, and sorting behavior. Do not assume that the first response contains every available offer or location.
Schema and error handling
Allow optional response fields, test mappings against the selected Amadeus product version, and classify invalid input, authentication failures, throttling, temporary availability issues, expired offers, validation failures, and unknown outcomes separately.
Why use Martini instead of scripts or point-to-point integrations?
Reusable orchestration
Martini centralizes Amadeus token handling, search, pricing, booking, enrichment, and reconciliation logic in maintainable workflows instead of scattering it across scripts and point-to-point implementations.
Consistent enterprise contracts
Martini can expose a stable REST API façade and transform Amadeus-specific flight, hotel, location, and reservation payloads into canonical models for multiple applications.
Operational control
Workflows provide a place to apply business rules, manage rate limits, separate safe from unsafe retries, preserve transaction state, and monitor failures across downstream systems.
Adaptable integration assets
Martini supports API consumption, mapping, validation, scheduling, error handling, and secure configuration so the integration can evolve when Amadeus products, target systems, or booking policies change.
Frequently asked questions
Amadeus is primarily integrated through its JSON-based REST APIs for flight and hotel search, offer pricing, flight orders, locations, destinations, airports, and travel recommendations. OAuth 2.0 client credentials provide bearer-token authentication, while scheduled workflows can support reconciliation where product-specific notifications are unavailable.
Yes. Martini can consume Amadeus REST APIs, implement the OAuth 2.0 client-credentials flow, map Amadeus JSON payloads, orchestrate search and booking workflows, expose a REST API façade, and synchronize supported reservation data with enterprise applications.
No. A dedicated Amadeus connector is not required. Martini can integrate using Amadeus's confirmed native REST APIs and OAuth 2.0 authentication, with workflows, mappings, validation, and scheduled processing providing the integration logic.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Amadeus. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Amadeus, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.
Use the Amadeus Self-Service REST APIs and OAuth 2.0 client credentials for new integrations in this scope. GraphQL was not confirmed, SOAP should be treated as legacy or product-specific, and general-purpose webhooks, file APIs, and direct database access were not confirmed.
A general-purpose Amadeus Self-Service webhook or outbound callback mechanism was not confirmed. Implementations should use a documented product-specific notification mechanism only when available; otherwise, a controlled scheduled retrieval and reconciliation workflow may be required.
Martini can map Flight Offers, Flight Orders, Hotel Offers, Locations, and related payloads into canonical enterprise models and target APIs. Synchronization should preserve Amadeus identifiers, use timestamps or other supported change criteria, and apply idempotency controls so retries do not create duplicate bookings or downstream records.
Yes. Martini can expose a controlled REST API that hides Amadeus-specific endpoints, validates caller input, applies enterprise travel policies, orchestrates search or booking calls, normalizes responses, and returns a stable contract to portals or internal applications.
Related Martini documentation
Workflows
Data Processing
Build a maintainable Amadeus integration with Martini
Use Martini to connect Amadeus REST APIs with travel portals, booking applications, customer systems, finance platforms, and operational workflows through secure API orchestration, reusable mappings, and controlled synchronization.