After Amadeus Self-Service: how to choose a flight API for search, booking and ticketing

Amadeus switched off its Self-Service APIs on 17 July 2026. The company announced earlier in the year that it was closing the self-service section of the Amadeus for Developers portal: new registrations were paused first, and on the shutdown date existing self-service keys stopped working and the portal went dark. The Enterprise APIs, available under a commercial agreement, continue unchanged.

For large travel companies this was a footnote. For startups, student projects, internal tools and smaller agencies it was the end of the easiest way to put real airline content behind a prototype. Many of those teams are now choosing a replacement under time pressure, and the market has responded with a wave of “drop-in alternatives” that are not all solving the same problem.

This guide is a vendor-neutral way to make that choice. It covers what the self-service tier actually provided, the four routes that remain, a checklist for evaluating any flight API, and a migration approach that does not lock you into the next provider the way many teams were locked into the last one.

What the self-service tier really gave you

It helps to be precise about what is being replaced, because teams often remember the free tier as more than it was.

The self-service catalogue offered REST APIs with OAuth2 client-credential authentication, a free but capped test environment, and a paid production environment with higher throughput. Most usage concentrated on a few endpoints: flight offer search, offer pricing, airport and city lookup, and some inspiration and analytics APIs. Booking endpoints existed, but in production the ability to actually issue tickets depended on having an arrangement with a consolidator or an accredited agency — the API alone did not make a company a ticketing agent.

So “replacing Amadeus Self-Service” can mean three very different things:

1. Replacing price data for a search page, a fare alert, a chatbot or a research project.
2. Replacing shopping and pricing that feed a booking flow handled elsewhere.
3. Replacing a full lifecycle — search, price, book, ticket, and service the booking afterwards.

Decide which of these you need before looking at a single vendor page. Most bad choices come from evaluating a provider built for the first job against requirements that belong to the third.

The four routes that remain

Route	Best for	What you get	What it costs you
GDS enterprise API	Established agencies and platforms with volume	Broadest legacy content, full servicing, deep control	Contract, certification, accreditation or ticketing partner, long lead time
Airline-direct NDC	Platforms where a few carriers dominate	Richest content and ancillaries from that airline	One integration, agreement and certification per airline
Aggregator or consolidator API	Startups, B2B platforms, OTAs moving fast	GDS, NDC and LCC content in one schema, ticketing under the provider	Another commercial layer, less control over edge cases
Price-data API	Search pages, alerts, analytics, AI assistants	Fares and schedules for display	Usually no booking, no ticketing, no servicing

GDS enterprise access

Going direct to a global distribution system is the most powerful option and the slowest. You negotiate a commercial agreement, certify your integration, and either hold IATA accreditation or ticket through a partner. In return you get the widest legacy content, full control over pricing and servicing messages, and the ability to tune everything. If you are already a mid-sized agency with stable volume, this is often where you end up anyway; the build-or-buy reasoning in build vs buy technology decisions applies directly.

Airline-direct NDC

Connecting straight to an airline’s NDC API gives the richest offers — branded fares, bundles and ancillaries exactly as the airline merchandises them. It also means one integration, one agreement and one certification per carrier, and two airlines on the same schema version can still behave differently. Direct NDC makes sense for the handful of carriers that dominate your market, rarely as the whole strategy.

Aggregators and consolidator APIs

An aggregator sits between you and many suppliers, normalises their content into one schema, and usually handles ticketing under its own accreditation and supplier agreements. This is the closest functional successor to what most self-service users wanted: one REST integration, a sandbox, and real bookable content without a GDS contract of your own.

Aggregators differ more than their marketing suggests. Some are flight-only; some combine air with hotels, transfers, activities and rail; some focus on one region’s low-cost carriers. Tripgic, for example, puts GDS, NDC and low-cost carrier content behind a single REST schema alongside hotels, transfers and rail, and publishes a migration path specifically for former self-service users. Others in the category make different trade-offs on coverage, pricing model and servicing depth — which is exactly why the checklist below matters more than any feature list. (Disclosure: the author is involved with Tripgic. The evaluation criteria below apply equally to every provider, including that one.)

Price-data APIs

Several replacements launched after the shutdown return live fares in a self-service-style format but cannot create an order or issue a ticket. Some derive prices from metasearch sources. For inspiration search, fare alerts, analytics and AI travel assistants, that can be entirely sufficient and far cheaper. The mistake is building a booking product on top of one and discovering the gap at checkout.

An evaluation checklist for any flight API

Demos are built around search, because search is the part that looks good. Use these questions to see the rest.

Content and coverage

• Which carriers matter on your routes, and through which channel does each one come — EDIFACT, NDC, or a low-cost carrier connection? Ask for coverage on your top twenty city pairs, not a global airline count.
• Are NDC offers returned with their full structure — fare families, baggage, seat and ancillary options — or flattened into a single price?
• How are duplicates handled when the same flight arrives through two channels at different prices?

The full booking lifecycle

• Can you price, book, ticket, void, cancel, refund and exchange through the API, or do some of these require an email to an operations desk?
• How are involuntary schedule changes delivered — polling, webhook or not at all? The servicing problems described in handling airline schedule changes do not disappear because someone else holds the ticketing.
• How are ticketing time limits exposed? An unticketed booking that silently expires is a support case waiting to happen; see ticketing time limits and PNR housekeeping.

Ticketing, liability and money

• Who issues the ticket and under whose accreditation? Who is the merchant of record for the card payment?
• Who carries agency debit memo risk if a booking breaks fare rules? The patterns in preventing ADMs are worth reading before signing any contract.
• What is the commercial model — flat fee per transaction, percentage, monthly minimum? Are there charges tied to search volume or your look-to-book ratio?

Engineering quality

• Is the sandbox realistic? It should return real schedules and realistic errors, not a handful of canned responses.
• Are booking calls idempotent? A retried booking request that creates a second reservation is expensive. Ask how the API behaves on a timeout; idempotency in booking and payment APIs explains why this question matters.
• What are the rate limits and quotas, and are searches and transactional calls limited separately? See supplier API rate limits and throttling.
• Are errors structured with stable codes, or free text copied from the underlying airline?
• Does the provider publish a changelog, an SLA and a status page? You will rely on all three.

Exit and lock-in

• Can you export your booking records in a usable format?
• Are booking references the airline’s own record locators, so bookings can be serviced elsewhere if you move?
• How much of your code would change if you replaced this provider next year?

That last question leads to the most important design decision in the whole migration.

Migrate behind your own port, not onto a vendor

The teams that suffered most on 17 July had Amadeus request and response objects spread through their codebase — in controllers, templates, database columns and analytics. Replacing the provider meant touching everything.

Do not repeat that with the next provider. Before writing any new integration code:

1. Define an internal flight contract — your own models for search request, offer, priced offer, booking and ticket — following the adapter approach in designing a booking engine for GDS and NDC.
2. Write the new provider as an adapter that maps into that contract at the edge. Nothing outside the adapter should know which supplier answered.
3. Store supplier references, not supplier payloads, in your booking tables. Keep raw payloads in a log store for debugging.
4. Build contract tests against recorded sandbox responses, so a provider schema change fails in CI rather than in production.
5. Add per-supplier observability — latency, error rate and booking success — before go-live, as described in observability for travel API integrations.
6. Cut over by route or market, not all at once, and compare price and availability against your expectations for the first weeks.

This adds a few days to the migration. It also turns the next provider change — and there will be one — from a rewrite into an adapter.

Common mistakes

• Choosing on search speed alone. Sub-second search is valuable; a booking flow that cannot void a ticket is worse than a slower one that can.
• Treating the sandbox as proof. Ask for production references on routes like yours, and run a small live pilot before committing volume.
• Ignoring servicing until after launch. Changes and refunds generate most operational cost in flight retail, and they are the hardest part to retrofit.
• Mixing data and booking providers without reconciliation. Showing a price from one source and booking through another guarantees price-change errors at checkout.
• Skipping the commercial read. Percentage-based pricing, minimums and search charges can make a technically good API uneconomic at your margins.

The short version

The end of Amadeus Self-Service removed an easy on-ramp, not the road. If you only need prices, a price-data API may be all you need. If you need to sell tickets without a GDS contract, an aggregator or consolidator API is the realistic successor — choose it on lifecycle completeness, liability terms and engineering quality rather than on airline counts. If you have the volume, a GDS enterprise contract supplemented by a few direct NDC connections remains the long-term destination.

Whichever route you take, put your own contract between your product and the supplier. The shutdown was a reminder that any external API can change its terms, and the cheapest time to prepare for that is before you write the integration.