Amadeus Quick Connect (AQC) API Integration
The Complete Developer & Business Guide (2026)

If you’re building a flight booking engine, an OTA (Online Travel Agency), or a corporate travel portal, chances are you’ve come across Amadeus Quick Connect (AQC). It promises enterprise-grade GDS connectivity, real-time airline inventory, and a faster path to market than legacy SOAP/XML-based integrations.

But what exactly is AQC? How does it differ from Amadeus Self-Service APIs? What does the integration lifecycle actually look like from authentication to ticket issuance? And what are the common pitfalls that burn development teams?

This guide covers all of it. No fluff, no marketing speak, just a thorough, practitioner-focused breakdown.

What is Amadeus Quick Connect?

Amadeus Quick Connect is a simple end-to-end API that provides access to superior flight offers, adapted to external experts with a traveller-oriented REST/JSON interface.

As part of the broader Amadeus airline distribution framework, AQC enables direct REST-based GDS connectivity, giving travel businesses full control over the airline booking lifecycle from availability search and pricing to PNR management, ancillary services, ticketing, and cancellations.

Unlike traditional Amadeus integrations that relied on SOAP/XML messaging (cryptic, verbose, and maintenance-heavy), AQC exposes a modern REST/JSON interface. This makes it dramatically easier for software developers to work with while still delivering the full depth and reliability of enterprise GDS connectivity.

What AQC gives you access to:

500+ full service and low-cost airlines from around the world, including NDC and Low-Cost content on top of standard Full Service carriers
Real-time flight availability and live seat inventory
Branded fare families (Basic Economy, Flex, Business, etc.)
Ancillary services — paid baggage, seat selection, meals
Full booking lifecycle: search → price → book → ticket → manage → cancel
PNR (Passenger Name Record) creation and management
Free and chargeable seats available through a seat map widget or through API, with content from more than 80 airlines
Automated ticket issuance post-payment

With Quick Connect, your API connection will allow your application, website, or integration into your current IMS to be up and running in 4 to 6 weeks. Whatever the air content, the API handles all the orchestration, organizing the actions sequencing itself.

AQC vs. Self-Service APIs vs. Enterprise APIs

One of the most common sources of confusion is understanding where AQC fits in Amadeus’s product lineup. Amadeus offers three main integration tiers: Self-Service APIs for developers who want to build applications with standard travel functionality; Enterprise APIs for large-scale implementations with custom requirements; and Quick Connect, a streamlined solution for rapid integration with pre-built connections.

Here’s a clear side-by-side comparison:

Self-Service APIs

Target: Startups, POC builds
Content: Public fares only
Integration: REST/JSON
Negotiated fares: No
Time to market: Days to weeks
Onboarding: Fully self-service

Quick Connect (AQC)

Target: OTAs, travel agencies, mid-to-large platforms
Content: GDS + NDC + LCC content
Integration: REST/JSON
Negotiated fares: Yes (via IATA/agency agreements)
Time to market: 4–6 weeks
Onboarding: Assisted by Amadeus team

Enterprise APIs

Target: Large enterprises, airlines
Content: Full custom access
Integration: SOAP/XML or REST
Negotiated fares: Yes
Time to market: 3–6 months
Onboarding: Dedicated project team

The Self-Service APIs rely on modern REST architecture and JSON format. As of 2026, the Self-Service suite comprises 30 APIs, organized into five categories. However, the catalog provides access only to public fares private or negotiated rates are available exclusively through the Enterprise tier.

Who Should Use AQC?

Amadeus Quick Connect Flight API integration allows travel agencies, online travel agencies (OTAs), and travel startups to connect their platforms with the Amadeus Global Distribution System. Through this integration, travel websites can access global airline inventory, retrieve live fares, validate pricing, and automate flight bookings.

AQC is purpose-built for:

OTAs that need real-time GDS connectivity and full booking automation
Corporate Travel Management Companies (TMCs) managing complex itineraries with policy enforcement
Travel startups that have moved past the POC stage and need production-grade inventory
Tour operators and travel aggregators bundling flights with hotels and activities
Technology companies building white-label travel booking engines for clients
Travel Management Systems (TMS) integrating airline booking into expense or HR platforms

When AQC is NOT the right fit:

If you’re just prototyping → use Self-Service APIs (free sandbox, simpler onboarding)
If you need custom airline-direct integrations → Enterprise APIs are more appropriate
If your transaction volume is very low → the economics may not work in your favour

Prerequisites Before You Start

Before you write your first AQC API call, make sure these are in order.

Business prerequisites:

IATA accreditation or affiliation with an IATA-accredited consolidator (required for ticketing)
BSP (Billing and Settlement Plan) membership or access through a host agency
An Amadeus commercial agreement — AQC is not self-signup; you work with an Amadeus sales and implementation team
A defined use case: B2C, B2B, or both, and whether you need NDC or LCC content

Technical prerequisites:

Reliable cloud infrastructure, secure API gateways, scalable backend systems, and high-performance databases
Backend developers comfortable with REST APIs, OAuth2, and JSON
Understanding of stateless API design — AQC is largely stateless, meaning each call stands alone except where session references are required
Familiarity with airline industry concepts: PNR, fare basis, IATA codes, baggage policies, ticketing deadlines

Authentication: OAuth2 Step-by-Step

AQC provides a secure, production-ready integration model powered by OAuth2 authentication and enterprise-grade transaction handling.

Step 1: Get your credentials

After your Amadeus commercial agreement is set up, you receive an API Key (client_id) and API Secret (client_secret). Keep these private and out of version control. Use environment variables or a secrets manager such as AWS Secrets Manager or HashiCorp Vault.

Step 2: Request an access token

Send a POST request to:

POST https://test.api.amadeus.com/v1/security/oauth2/token

Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

&client_id=YOUR_API_KEY

&client_secret=YOUR_API_SECRET

The body of the request is encoded as x-www-form-urlencoded, where the keys and values are encoded in key-value tuples separated by &, with a = between the key and the value. Amadeus

Step 3: Parse the token response

json
{
  “type”: “amadeusOAuth2Token”,
  “token_type”: “Bearer”,
  “access_token”: “eyJhbGc…”,
  “expires_in”: 1799,
  “state”: “approved”
}

The access token is valid for approximately 30 minutes (1799 seconds). Store it server-side and reuse it across requests until close to expiry.

Step 4: Use the token in all API calls

Include it as a header on every request:

Authorization: Bearer eyJhbGc.

Token management best practices:

Reuse the same token until it expires rather than requesting a new token for every search. Automate OAuth2 authentication to refresh tokens proactively and handle 401 and 429 responses gracefully.
Implement proactive refresh when less than 60 seconds remain
In production with multiple backend instances, store the token in a shared Redis cache

–

The Core AQC API Workflow

The AQC booking journey follows a fixed, sequential flow. Understanding this sequence is critical skipping steps or reordering them causes booking failures.

Search → Price → Book → Ticket → Manage / Cancel

Stage 1: Flight Offers Search

Endpoint: GET /v2/shopping/flight-offers

This is the entry point. Because the API is stateless and offer-based, every search produces fresh, time-sensitive results directly from the GDS.

Key request parameters:

originLocationCode = DEL

destinationLocationCode = LHR

departureDate = 2025-09-15

returnDate = 2025-09-25

adults = 2

travelClass = ECONOMY

currencyCode = USD

max = 20

sources = GDS

Sample response (simplified):

json
{
  “data”: [{
    “id”: “1”,
    “source”: “GDS”,
    “instantTicketingRequired”: false,
    “lastTicketingDate”: “2025-08-01”,
    “numberOfBookableSeats”: 7,
    “itineraries”: [{
      “duration”: “PT9H25M”,
      “segments”: [{
        “departure”: { “iataCode”: “DEL”, “at”: “2025-09-15T01:30:00” },
        “arrival”: { “iataCode”: “LHR”, “at”: “2025-09-15T06:55:00” },
        “carrierCode”: “BA”,
        “number”: “258”
      }]
    }],
    “price”: {
      “currency”: “USD”,
      “total”: “1245.60”,
      “grandTotal”: “1245.60”
    }
  }]
}

Important notes:

The total price in Search is indicative, not locked in. Always call the Flight Offers Price API before final booking.
lastTicketingDate is critical missing it triggers booking failures
numberOfBookableSeats shows remaining availability at that price point
instantTicketingRequired: true means the ticket must be issued immediately upon booking

Stage 2: Flight Offers Pricing

Endpoint: POST /v1/shopping/flight-offers/pricing

The Flight Offers Pricing API establishes transactional integrity within an AQC integration. It confirms availability, fare basis accuracy, ancillary eligibility, payment compliance, and updated ticketing conditions. Because the API is stateless and offer-based, every pricing request recalculates the offer directly against live airline inventory.

You pass the entire offer object from the Search response. Do not modify any structural fields.

Key fields to check in the response:

json
{
  “data”: {
    “flightOffers”: [{
      “price”: {
        “total”: “1247.80” // May differ from Search price
      },
      “fareDetailsBySegment”: [{
        “cabin”: “ECONOMY”,
        “fareBasis”: “YLWF2AU”,
        “class”: “Y”,
        “includedCheckedBags”: { “quantity”: 1 }
      }]
    }]
  }
}

Best practices:

Always compare the Pricing response price with the Search price and surface any difference to the user before proceeding
Store the full Pricing response — you’ll pass it verbatim to Create Order
Pricing is mandatory even if no ancillaries are selected. Seat availability and fare validity must still be confirmed.

Stage 3: Flight Create Orders (Booking)

Endpoint: POST /v1/booking/flight-orders

This creates the PNR in the Amadeus GDS. This is the point of commitment.

Sample request body:

json
{
  “data”: {
    “type”: “flight-order”,
    “flightOffers”: [ /* full priced offer from Pricing API */ ],
    “travelers”: [{
      “id”: “1”,
      “dateOfBirth”: “1985-03-22”,
      “name”: { “firstName”: “RAHUL”, “lastName”: “SHARMA” },
      “gender”: “MALE”,
      “contact”: {
        “emailAddress”: “rahul.sharma@example.com”,
        “phones”: [{ “deviceType”: “MOBILE”, “countryCallingCode”: “91”, “number”: “9876543210” }]
      },
      “documents”: [{
        “documentType”: “PASSPORT”,
        “number”: “P1234567”,
        “expiryDate”: “2030-01-14”,
        “issuanceCountry”: “IN”,
        “nationality”: “IN”,
        “holder”: true
      }]
    }],
    “ticketingAgreement”: {
      “option”: “DELAY_TO_CANCEL”,
      “delay”: “6D”
    }
  }
}

Passenger data rules (critical):

Airline systems are sensitive to passenger data formatting. Small mistakes can cause booking failures. Names must match the travel document exactly.
Passport number, expiry, and issuing country are required for international flights
dateOfBirth format: YYYY-MM-DD

The response contains two references you must store:

json
{
  “data”: {
    “id”: “MJ0MBSLTA0”, // AQC Order ID
    “associatedRecords”: [{
      “reference”: “T85MS6” // GDS PNR reference — show this to the customer
    }]
  }
}

Store both. The AQC Order ID is used to manage the booking via API. The GDS PNR reference is what airlines and check-in systems recognise.

Stage 4: Seat Maps and Ancillaries

Endpoint: POST /v1/shopping/seatmaps

Request available seats for a flight offer or an existing booking. The response includes seat class (window, aisle, exit row), availability status, and pricing for paid seats. Seat map content is available from more than 80 airlines. For unsupported airlines, display a “seat selection at check-in” message.

Stage 5: Ticket Issuance

Endpoint: POST /v1/orders/{orderId}/tickets

After payment is processed on your platform, trigger ticket issuance. This calls the airline reservation system and issues the e-ticket, generating the 13-digit ticket number.

Handling instantTicketingRequired:

If true: issue the ticket immediately after booking build this directly into your payment confirmation flow
If false: you have until lastTicketingDate but never let it get close; automate ticketing within minutes of payment confirmation

Stage 6: PNR Management and Cancellations

Get order: GET /v1/booking/flight-orders/{orderId}

Cancel order: DELETE /v1/booking/flight-orders/{orderId}

For cancellations, always check the fare rules first most Economy fares are non-refundable. Surface cancellation policy clearly to users before booking is confirmed.

Stage 7. System Architecture for AQC Integration

A production-grade AQC integration involves multiple layers. Here is a recommended architecture pattern:

User Interface (Web / Mobile / B2B Portal)

↓

API Gateway / BFF Layer

(Rate limiting, auth validation, logging)

↓

Booking Engine Backend

Search Service
Pricing Service
Order Manager (PNR + Tickets)

↓

AQC API Client Layer

(Token management, retry logic, rate limiting)

↓

Amadeus Quick Connect (GDS / NDC / LCC)

Recommended technology components:

Backend: Node.js, Python, Java, or .NET (Amadeus provides SDKs for all)
Caching: Redis (tokens, search results, offer metadata)
Queue: RabbitMQ or AWS SQS (async ticketing jobs)
Database: PostgreSQL for booking records
Secrets: AWS Secrets Manager or HashiCorp Vault
Monitoring: Datadog, New Relic, or Prometheus + Grafana

Key Technical Considerations

1. Statefulness in a stateless API

AQC APIs are mostly stateless but the booking flow has an implicit state machine. You cannot skip stages. Pricing output must reference Search output; Create Order must reference Pricing output; Ticketing must reference the Order ID. Use Redis with a session TTL to hold intermediate offer data between steps.

2. Fare volatility

Flight prices change constantly. Best practices: always call Pricing before displaying the final price on the checkout screen; set a reasonable offer validity timer in your UI (5–10 minutes); if the price changes between Pricing and Order creation, surface the new price to the user and request re-confirmation.

3. Content sources: GDS vs NDC

json
“sources”: [“GDS”] // Traditional GDS content
“sources”: [“NDCX”] // NDC airline direct content
“sources”: [“GDS”, “NDCX”] // Mixed — returns combined results

NDC content often includes exclusive offers not available via traditional GDS, but requires more complex response handling. Ensure your response mapper handles both content types gracefully.

Common Mistakes and How to Avoid Them

Using Search price as the final booking price Impact: Price discrepancies, booking failures Fix: Always call Pricing before Create Order
Requesting a new OAuth token per API call Impact: Added latency, rate limit hits Fix: Cache and reuse tokens until near expiry
Not handling lastTicketingDate Impact: Missed ticketing deadlines, automatic cancellations Fix: Automated ticketing job triggered immediately on payment confirmation
Incorrect passenger name formatting Impact: Booking rejections at airline level Fix: Validate names against passport exactly; use all caps
Caching flight offers too long Flight offers are time-sensitive. Excessive caching can lead to ghost availability and increased booking failures.
Fix: Cap offer cache at 5–10 minutes maximum
Modifying the offer object between Pricing and Booking Impact: API rejections Fix: Pass the full Pricing response verbatim to Create Order
Not storing the GDS PNR reference Impact: Unable to manage or cancel bookings Fix: Always store both the AQC Order ID and the GDS PNR reference
No retry logic on 429 and 503 responses Impact: Silent booking failures under load Fix: Implement exponential backoff with jitter

Performance Optimization Tips

Parallel requests where possible: For multi-destination or multi-passenger searches, split into parallel API calls and aggregate results. Search is read-only — safe to parallelise.

Response compression: Enable gzip/brotli on both your server and Amadeus API calls. Search responses can be large — compression meaningfully reduces payload sizes.

Smart caching strategy:

OAuth token: cache until 60 seconds before expiry
Flight offers: maximum 3–5 minutes
Airline logos and airport metadata: cache aggressively (days to weeks)
Fare rules: cache per fare basis code for hours

Connection pooling: Maintain a persistent HTTP connection pool to Amadeus endpoints. Creating new TCP connections per request adds measurable latency at scale.

Asynchronous ticketing: Never block the booking confirmation screen on ticket issuance. Accept payment, create the PNR, confirm to the user, then issue the ticket via a background job.

Load testing: Before go-live, simulate peak traffic at 150% of projected volume. Bottlenecks in your own middleware will surface under load — better to find them in testing.

Testing Strategy

Sandbox environment

Amadeus provides engineers with a test environment, code samples, and SDKs that simplify API embedding. The sandbox environment allows your application to make up to 10 requests per user per second.

Sandbox base URL: https://test.api.amadeus.com

What to test:

Unit tests: Mock AQC responses and test your parsers, validators, and business logic independently.

Integration tests against sandbox: Cover the full flow — auth → search → price → book → ticket → cancel.

Edge cases to specifically target:

Price change between Search and Pricing
instantTicketingRequired: true offers
NDC content alongside GDS content
Multi-segment and multi-city itineraries
Infant passengers (special handling requirements)
Passport expiry validation (must be 6+ months beyond travel date)

Load tests: Use k6 or Locust against your backend to simulate concurrent searches at peak volume before go-live.

Go-Live Checklist

OAuth2 token management implemented with automatic refresh
Full search → price → book → ticket flow tested end-to-end in sandbox
instantTicketingRequired handling implemented and tested
lastTicketingDate monitoring and automated ticketing job in place
Passenger data validation implemented (name, passport, DOB, contact details)
Price change detection between Search, Pricing, and Create Order stages
GDS PNR reference stored in your database alongside the AQC Order ID
Cancellation and refund flows implemented and tested
Error handling and retry logic for 401, 429, 500, and 503 responses
Logging and monitoring in place (request IDs, response times, error rates)
Secrets stored in a secure vault — not in code or environment files
Load testing completed at 150% of projected peak traffic
IATA/BSP settlement workflow confirmed with your host agency
Production AQC credentials received and smoke-tested
Amadeus implementation team sign-off completed

Amadeus Quick Connect (AQC) is one of the most capable airline booking APIs available today. It gives travel platforms real-time GDS access, full booking lifecycle automation, and connectivity to 500+ airlines all through a modern REST/JSON interface that experienced backend developers can work with efficiently.

The integration is not trivial. You need proper architecture, smart token management, stateful offer handling, and thorough edge case testing. But teams that invest in getting it right will have a rock-solid foundation for building scalable, revenue-generating travel platforms.

The key principles to take away:

Always price before booking never trust the Search price as final
Manage OAuth2 tokens efficiently cache and reuse, never recreate per call
Treat instantTicketingRequired and lastTicketingDate as first-class engineering concerns
Validate passenger data rigorously before calling Create Order
Build an async ticketing pipeline so the user experience never waits on ticket issuance

If you’re planning an AQC integration, start with the Amadeus for Developers sandbox to build confidence, then work with the Amadeus team to provision AQC production access when your architecture is solid and tested.

Read More: Why Amadeus Matters in Today’s Travel Ecosystem

FAQ’S

1. How long does Amadeus AQC onboarding take?

With Quick Connect, your integration will allow your application to be up and running in 4 to 6 weeks.This assumes your IATA/BSP setup is ready and a dedicated development resource is assigned.

2. Do I need IATA accreditation to use AQC?

For ticketing, yes you need either direct IATA accreditation or access through an IATA-accredited host agency. For search-only use cases, the requirement is more flexible. Confirm specifics with Amadeus during commercial discussions.

3. Can AQC return low-cost carrier content?

Yes. AQC integrates NDC and Low-Cost content on top of standard Full Service carriers. Coverage varies by airline and region confirm your specific LCC requirements with Amadeus during onboarding.

4. What is the difference between the AQC Order ID and the GDS PNR reference?

The AQC Order ID is Amadeus’s internal reference for managing the booking through the API. The GDS PNR reference (e.g. T85MS6) is the airline-visible record locator the one you show customers and that airline check-in systems recognise. You need both and must store both.

5. Is there an SDK for Amadeus AQC?

Amadeus provides SDKs in Ruby, Python, Java, Node.js, .NET, Kotlin (Android), and Swift (iOS), available through their official GitHub repository. These handle authentication, request formatting, and response parsing significantly reducing integration time.

6. What happens if a booking fails after payment is charged?

Implement a transaction compensation pattern: if the Create Order call fails after payment is charged, immediately trigger a refund via your payment gateway. Maintain a reconciliation log of payment and booking events to catch and handle these edge cases. Never rely on the user to report them.

7. How are prices settled between my platform and airlines?

This is handled through BSP (Billing and Settlement Plan) via IATA. Your agency settles with airlines through BSP on a regular cycle, typically weekly. Your Amadeus account configuration, IATA membership, and host agency relationships determine the specifics.

Let's Start Your Project

Let us help you achieve your goals, by creating the best solution for you!

Amadeus Quick Connect (AQC) API Integration Guide

Amadeus Quick Connect (AQC) API IntegrationThe Complete Developer & Business Guide (2026)