Amadeus's own self-service documentation groups more than a dozen distinct flight related endpoints under a single Flight APIs category, which is exactly why "flight API" and "flight search API" get treated as interchangeable even though they describe different scopes of work. This is the umbrella term. It groups together every flight related endpoint Amadeus offers under its self-service and Enterprise catalogs, including:

• Flight Offers Search, for returning available flights and fares
• Flight Offers Price, for re-confirming a fare right before booking
• Flight Create Orders, for finalizing a booking and generating a PNR
• Flight Cheapest Date Search, for showing the lowest fares across a date range
• Flight Inspiration Search, for suggesting destinations based on budget
• Flight Delay Prediction and Flight Choice Prediction, both built on machine learning models trained on historical booking data
• Airport and City Search, for autocomplete during the search step

When someone uses that phrase to describe an integration project, they usually mean some combination of these endpoints, not one single call. Scoping a project against this whole category, rather than one endpoint, is what separates an accurate estimate from a rushed one.

The Amadeus flight search API, more precisely called Flight Offers Search in Amadeus's own documentation, is the single endpoint responsible for returning available flights. A user submits an origin, destination, and dates, and the API queries live inventory across more than 500 airlines, returning flight offers with prices, fare details, and baggage allowances included.

This is the first step in any Amadeus travel API integration for a booking flow, but it's only the first step. Flight Offers Search does not confirm the fare is still bookable and does not create the reservation. Those jobs belong to Flight Offers Price and Flight Create Orders respectively, which is the core reason conflating the two causes real scoping problems: a team that builds only the search call has built a fraction of a working booking engine, not the whole thing.

The Flight API Category

This refers to the entire set of flight related endpoints under Amadeus, spanning search, pricing, booking, prediction, and airport data. Scoping a project around this category means accounting for multiple endpoints working together, not a single integration point.

The Flight Search API Specifically

This refers to one endpoint within that broader set, responsible only for returning available flights and fares based on a route and date. It's the entry point of a booking flow, not the entire flow.

One line takeaway: the flight API is the whole toolbox, the flight search API is one tool in it, and a booking platform needs several tools from that box, not just the one that returns search results.

A working Amadeus API integration chains three calls together in sequence. Flight Offers Search returns available options. Flight Offers Price re-validates the fare and availability right before checkout, since prices and inventory shift constantly between search and booking. Flight Create Orders then finalizes the reservation against a Passenger Service System, or PSS, generating the actual booking record.

Skipping the price confirmation step to reduce latency is a common shortcut we see teams take, and it's how platforms end up quoting fares that are no longer valid by the time a customer completes checkout. For platforms that want a narrower, faster entry point into this flow without building against the full Enterprise catalog, a flight search API integration solution built around Amadeus Quick Connect covers search, pricing, and booking specifically, without requiring the full scope of Enterprise onboarding upfront.

This distinction matters more than usual right now because Amadeus access itself is changing. Amadeus confirmed it is decommissioning its self-service developer portal, the tier most smaller platforms used to prototype against Flight Offers Search and the rest of that category. Travel technology press reporting on the announcement noted new self-service registrations were paused starting in March 2026, with existing self-service API keys disabled in mid-July 2026. Enterprise access and Quick Connect remain unaffected.

For any platform still scoping which endpoints to build against, this means the access path matters as much as the endpoint list. A project planned around self-service pricing and sandbox access needs a different budget and timeline than one planned around Enterprise or Quick Connect from the start. As a flight booking technology provider working across all three access tiers, that's exactly the kind of scoping detail our parent company, OneClick IT Solution, accounts for across its broader travel technology services, since getting the access tier wrong early tends to cost more to fix later than it would have cost to plan correctly the first time.

Build against Flight Offers Search first if:

• You're validating demand for a new route or market before committing to a full booking flow
• Your immediate goal is a search and compare page, not live booking
• You want to test API response times and data quality before scoping the rest of the build

Add Flight Offers Price and Flight Create Orders next if:

• You're ready to accept live bookings, not just display search results
• Your platform needs a real PNR generated for each confirmed booking
• You're building toward a full flight booking engine rather than a search widget

Consider the prediction and inspiration endpoints, like Flight Delay Prediction or Flight Inspiration Search, only after the core search, price, and book flow is stable, since these add value on top of a working booking flow rather than replacing any part of it. For a deeper breakdown of how these endpoints fit into a full booking engine build, our flight API blog covers related integration topics in more depth.

What is the difference between the Amadeus flight API and the Amadeus flight search API? 

The first is the full category of flight related endpoints, including search, pricing, booking, and prediction tools. The second refers specifically to Flight Offers Search, the one endpoint that returns available flights and fares.

Is Flight Offers Search enough to build a flight booking engine? 

No. Flight Offers Search only returns search results. A working booking engine also needs Flight Offers Price to re-confirm the fare and Flight Create Orders to finalize the reservation, so at minimum three endpoints work together in sequence.

Does the Amadeus flight search API include pricing and booking? 

No. Pricing confirmation happens through the separate Flight Offers Price API, and booking happens through Flight Create Orders. The search API's job ends once it returns a list of available flight offers.

How many endpoints does Amadeus offer under its flight category? 

Amadeus groups more than a dozen distinct endpoints under its Flight APIs category, covering search, pricing, booking, airport autocomplete, and machine learning based prediction tools like flight delay and flight choice prediction.

Is Amadeus shutting down its self-service flight search API access? 

Yes, for the self-service tier specifically. Amadeus is decommissioning its self-service developer portal, with existing API keys disabled in mid-July 2026, while Enterprise and Quick Connect access remain unaffected.

Which Amadeus flight API should I integrate first for a new platform? 

Most teams start with Flight Offers Search to validate demand and test data quality, then add Flight Offers Price and Flight Create Orders once they're ready to accept live bookings rather than just display search results.