If you're building a travel portal, one of the first real decisions is which global distribution system to connect to — and the three big names, Amadeus, Sabre and Travelport, get compared as if one is simply "the best." They aren't ranked that way in practice. They're three large, mature systems that overlap heavily and differ in ways that matter enormously for your portal and barely at all in the abstract. Here's how they actually differ, and how to choose — from someone who runs a live platform sitting on top of more than one of them.

First, the thing every comparison should say up front: a GDS is a distribution network. It aggregates flights, hotels, car hire and other travel content from thousands of providers and exposes it through one connection, so your portal can search and book across the industry without integrating each airline and hotel chain yourself. Amadeus, Sabre and Travelport are the three that dominate that role globally. All three do fundamentally the same job. So the question isn't "which one is good" — they're all good — it's "which one fits what I'm building and who I'm selling to."

That's why a blanket "use X" recommendation is worth ignoring. The right GDS depends on your target market, the content you need, the commercial terms you can get, and how much engineering you want to take on. Let's go through each of those, then the three systems, then how to actually decide.

The three, at a glance

Here's the honest high-level shape of each. Treat these as tendencies, not laws — all three carry global content, and their exact coverage and terms shift with the deals airlines and agencies strike.

The honest headline: for most portals the deciding factor isn't which brand is "biggest," it's which one has the best content and commercial terms for your specific market. A smaller GDS with a great deal and the right coverage beats the biggest name on paper.

The factors that actually decide it

1. Your target market and routes

This is the first and biggest filter. Where do your customers fly and stay? A portal built for European and long-haul international travel usually finds Amadeus the natural fit; one aimed at North American domestic and cross-border travel often leans to Sabre; Travelport is a serious option across several regions and frequently the one that competes hardest on terms. Match the GDS's regional strength to your actual demand and half the decision is made — because content and fares that are excellent in one region can be thinner in another.

2. Content: air, hotel, car — and NDC

"Flights" isn't one thing. You need to check that the GDS carries the airlines your customers actually want, at competitive fares, plus the hotel and car content if you're selling those. A growing piece of this is NDC (New Distribution Capability) — the newer standard airlines use to distribute richer fares and ancillaries like seats and bags. All three GDSs are building out NDC content, but the depth varies by carrier and by GDS, and it matters more every year. If a specific airline's full fare range is core to your business, verify how each GDS carries it before you choose.

3. Commercial terms and cost

GDS access is a negotiated commercial agreement, not a public price list. Terms vary with your booking volume, market and content needs, and can involve segment fees, minimums and incentives that swing the real cost significantly. This is why the "best" GDS is partly whichever gives you the best deal — a challenger hungry for your segment may offer terms the market leader won't. You negotiate directly with the GDS, or reach one through an aggregator, and the deal is a genuine input to the choice, not an afterthought. I've written more on how these costs feed into a build in what it costs to build a booking engine.

4. The API and the engineering reality

Each GDS exposes its content through its own APIs, and they are not interchangeable — different data models, different booking flows, different quirks and legacy corners. Whichever you pick, the integration is real work: managing sessions and pricing, handling the confirm-price-before-book flow, dealing with time-outs and errors gracefully, and keeping the connection stable in production. The GDS with slightly better content but a far messier API can cost you more in the long run than a marginally smaller one that's cleaner to build on. This is exactly the kind of trade-off worth weighing with an engineer who's integrated one before, not just a salesperson.

Do you have to pick just one?

No — and many serious portals don't. Running more than one GDS widens your content and fare coverage, strengthens your hand on commercial terms, and means you're not wholly dependent on a single provider's uptime or pricing. The trade-off is engineering: every GDS you add is another API, another data model and another set of failure modes to handle.

The right way to do it — and the way I've built it — is to put an abstraction layer between your portal and the GDSs. The rest of your system talks to one internal interface for "search flights" or "book this fare," and behind that interface you can have one GDS today and three tomorrow without rewriting the portal. It also lets you route a search to whichever provider has the best fare or content for that request. If multi-GDS is where you're heading, that architecture is the whole game; I've written it up in detail in how to integrate multiple GDS providers into one booking engine. And if you're leaning toward Amadeus specifically, there's a full walkthrough in integrating the Amadeus API into a B2B travel portal.

How to actually decide

Strip it back to a short, honest process. Start with your market and routes and shortlist the GDS whose regional strength matches your demand — that usually narrows it to one obvious lead and one challenger. Confirm each carries the airline, hotel and car content your customers need, with real attention to NDC for any airline central to your model. Then talk terms with both, because the commercial deal can flip the decision, and factor in the engineering effort of each one's API. If you have the volume and the ambition, plan for more than one from the start by building behind an abstraction layer — but launch with the single best fit rather than waiting to integrate everything.

What you should not do is pick the biggest brand by reputation and assume it's right. I've seen portals over-pay for the market leader when a challenger had better terms and equal content for their region, and I've seen portals under-serve their customers by choosing on price alone and missing the airlines those customers actually wanted. The decision is specific to you — and it's cheap to get right up front and expensive to change once your bookings depend on it.

GDS comparison FAQs

What is the difference between Amadeus, Sabre and Travelport? All three are global distribution systems that let a travel portal search and book flights, hotels and cars from thousands of providers through one connection. The practical differences are geographic strength (Amadeus is strongest in Europe and globally, Sabre in North America, Travelport competes across several regions), the exact airline and hotel content each carries, their APIs and NDC support, and the commercial terms you can negotiate. For most portals the deciding factor is which one has the best content and terms for your target market.

Which GDS is best for a travel portal? There is no single best GDS — it depends on where your customers travel, what content you need, and the commercial deal you can get. A portal serving European or global routes often starts with Amadeus; one focused on North America often leans to Sabre; Travelport is a strong option and frequently the challenger on price and terms. The right answer is the GDS whose content and pricing fit your market, not the biggest name.

Can a travel portal use more than one GDS? Yes, and larger portals often do — to widen fare and content coverage, to negotiate better terms, and to avoid depending on a single provider. The catch is that each GDS has its own API and quirks, so connecting several is far more work than one. The clean way to do it is to build an internal abstraction layer so the rest of your system talks to one interface while multiple GDSs sit behind it.

How much does GDS access cost? GDS access is a commercial agreement, not a public sign-up, so there is no list price. Terms vary by provider, your booking volume, your market and what content you need, and can involve segment fees, minimums and incentives. You negotiate directly with the GDS or go through an aggregator, and the deal you can get is itself one of the factors in choosing between them.

Do I need a GDS or can I use direct airline APIs and NDC? It depends on your model. A GDS gives you broad multi-airline content through one connection, which is why most portals start there. Direct airline APIs and NDC can give richer content and better fares for specific carriers, but connecting many airlines directly is a lot of integrations to build and maintain. Many modern portals use a mix — a GDS for breadth plus direct or NDC connections for key airlines — behind a single booking layer.

I build travel portals and booking engines on top of the major GDSs — and I run a live platform that sits on more than one. If you're choosing a GDS or building on top of one, see my travel portal development service or get in touch.

Originally published at sunnybadgujar.com.

Amadeus is where most travel portals start, and for good reason: it's the largest GDS, the content is deep, and the modern Amadeus for Developers APIs are plain REST with JSON — no arcane messaging formats to learn on day one. But there's a gap between "I can search flights from a code sample" and "I've shipped a B2B travel portal that sub-agents actually book on." This post is about closing that gap.

I run a travel reservation platform that integrates Amadeus alongside other suppliers end to end — search, pricing, booking, refunds, agent wallets and markup. Below is the integration path I'd hand to someone starting today, in the order the decisions actually come up.

First decision: Self-Service or Enterprise?

Before you write a line of code, you have to know which Amadeus you're building against, because they are not the same product.

• Amadeus Self-Service APIs. Sign up on the developer portal, get an API key in minutes, and you're calling a free test environment the same day. REST/JSON, pay-as-you-go pricing in production, no commercial negotiation. Perfect for MVPs, prototypes, and portals with moderate volume. The catch: the content and functionality are a curated subset of full GDS capability.
• Amadeus Enterprise (the full travel platform). Full GDS content, ticketing, richer fare and ancillary support — but it requires a commercial agreement, an office ID, and a heavier onboarding. This is what large agencies and consolidators run on.

Practical advice: build your MVP on Self-Service. Its data model and flow mirror the enterprise concepts closely enough that if you keep Amadeus behind an adapter (more on that below), moving up later is an integration change, not a rewrite. Don't block your launch on an enterprise contract you don't need yet.

Everything that follows uses the Self-Service REST flow, because that's where 90% of new B2B portals begin.

Authentication: one token, cached, refreshed

Amadeus uses OAuth2 client credentials. You exchange your API key and secret for an access token, and you send that token as a bearer header on every subsequent call. The token is short-lived — roughly 30 minutes — so you cache it and refresh before it expires rather than requesting a new one per call.

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

// response
{ "access_token": "abc123...", "expires_in": 1799, "token_type": "Bearer" }

Wrap this in a small token provider that stores the token in memory with its expiry and hands out a valid one on demand. Requesting a fresh token on every search is a classic early mistake — it adds a round-trip to every request and burns quota for no reason.

Two environments, two base URLs: test.api.amadeus.com serves cached, non-live data for development; api.amadeus.com is production with live pricing and real bookings. They use different credentials. Make the base URL and keys configuration, never hard-coded — you will switch between them constantly.

The core flight flow is three calls, in order

This is the single most important thing to internalise about Amadeus, and it maps directly to how travel actually works: search is indicative, price is live, and only then can you book. Three endpoints, always in this sequence:

1. Flight Offers Search — POST /v2/shopping/flight-offers. Send origin, destination, dates, passenger counts, cabin. Get back a list of offers, each with a full fare breakdown and an offer object you carry forward. This is what populates your results page.
2. Flight Offers Price — POST /v1/shopping/flight-offers/pricing. Take the exact offer the customer selected and confirm it live. Amadeus revalidates availability and price and returns the current, bookable fare. This is where you catch price drift before it costs you money.
3. Flight Create Orders — POST /v1/booking/flight-orders. Send the confirmed offer plus traveller details, and Amadeus creates the booking (a PNR). This is the step that actually reserves seats.

Skipping the middle step is the most expensive bug in the category. If you book straight off the search result, you'll routinely try to sell fares that have already changed or sold out — and you eat the difference or fail the booking at the worst possible moment. The price call exists precisely so you re-confirm the fare the instant before you charge the customer.

Booking is two steps for the same reason. Confirm price live, then take payment, then create the order. If order creation fails after you've charged, you must automatically void or refund — never leave an agent's wallet debited for a PNR that doesn't exist.

Now the part the docs don't cover: this is a B2B portal

A consumer booking site has one customer type. A B2B portal has agents — sub-agents, sub-sub-agents, corporate clients — each of whom logs in, sees their own fares, and books against their own money. That changes the architecture in four concrete ways.

1. Multi-tenancy and roles

Your data model needs a tenant hierarchy from day one: the portal owner at the top, then agencies, then the individual agents who log in. Every booking, every wallet transaction, every markup rule is scoped to a node in that tree. Retrofitting multi-tenancy after launch is painful — bake the agency/agent relationship into your schema and every query before you have live data.

2. The markup engine

Amadeus returns net fares. Your agents must never see the net — they see the price after your markup. So between the pricing call and the response you send to the browser, you run a markup engine that adds a margin. And it's rarely a flat number: markup varies by agency, by route, by airline, by fare class, sometimes as a percentage and sometimes as a fixed amount per passenger.

// conceptual: applied server-side, never in the client
sellFare = netFare + resolveMarkup(agencyId, route, airline, fareClass);
// the agent sees sellFare; the net stays server-side only

Two rules keep this safe. First, markup is applied on the server, always — the net fare must never reach the browser, or an agent will read it in the network tab. Second, you store both the net and the sell price on the booking record, so your reconciliation and commission reports are accurate later.

3. Agent wallets and credit

B2B agents don't pay by card per booking. They top up a wallet (or get a credit line), and each booking debits the balance. That means your booking flow has an extra gate: check the agent has sufficient balance before you call Flight Create Orders, then debit atomically as part of confirming the booking.

• Model the wallet as an immutable ledger — append credits and debits, never edit a running total. The balance is the sum of entries. This makes disputes auditable and prevents a whole class of race-condition bugs.
• Debit and booking must succeed or fail together. If the Amadeus order fails, the debit reverses; if the debit fails (insufficient funds), the order is never attempted.
• Cancellations and refunds credit the wallet back, minus any airline penalty — as a background job with retries, because refund calls fail transiently.

4. Credential and quota management

On Self-Service, the whole portal typically shares one set of production Amadeus credentials, so your rate limiting and quota tracking are portal-wide — one noisy agency hammering search can throttle everyone. Enforce per-agency rate limits inside your own layer so no single tenant can exhaust the shared quota. (On enterprise, you may have per-office-ID credentials, which changes this calculus — another reason to keep Amadeus behind an adapter.)

Keep Amadeus behind an adapter — even if it's your only supplier

It's tempting, when Amadeus is your only integration, to call it directly from your booking code. Don't. Define your own internal types — a FlightOffer, a PriceBreakdown, a BookingResult — and make an Amadeus adapter translate into them. Your search page, booking flow and admin panel work only with your model and never import Amadeus specifics.

You get two payoffs. Moving from Self-Service to enterprise later becomes an adapter change instead of a rewrite. And the day you add a second supplier — a low-cost carrier aggregator, a direct hotel feed, another GDS — you write one more adapter and the rest of the system doesn't notice. That multi-supplier architecture is a topic in itself; I've written it up separately in how to integrate multiple GDS providers into one booking engine.

Caching, rate limits and the test-data trap

GDS calls cost money and are rate-limited, so treat them accordingly:

• Cache searches briefly. A 30–120 second cache keyed on route and dates absorbs pagination and repeat searches without re-hitting Amadeus. Never cache long enough to serve a stale fare into a booking — the live price call is your safety net, but don't lean on it to paper over reckless caching.
• Rate-limit per agency, inside your layer. As above, the shared Self-Service quota means one tenant can starve the rest unless you police it yourself.
• Remember the test environment is not live. Test data is cached and limited — some routes return nothing, prices aren't real, and a "successful" test booking isn't a real reservation. Validate business logic in test, but only trust behaviour you've re-checked against production before you go live.

The admin panel is half the product

None of the above is visible to your operations team unless you build for them. An internal admin panel — showing every booking with its agency, net and sell fare, wallet transaction, PNR and refund state, plus a full audit log of what you sent Amadeus and what came back — is how support resolves a stuck booking at midnight without reading raw API logs. In a B2B portal it's not optional: it's where you manage agents, set markup rules, top up wallets and investigate disputes. Build it alongside the engine, not after.

Pitfalls I'd flag before you start

• Never skip Flight Offers Price. Search prices are indicative; confirm live before every charge.
• Never let the net fare reach the browser. Apply markup server-side; store both net and sell on the booking.
• Make wallet and booking atomic. A retried booking or refund must never double-charge or double-credit an agent.
• Don't hard-code the environment. Test and production have different URLs and keys — make them configuration.
• Don't call Amadeus directly from business code. The adapter is what lets you grow from Self-Service to enterprise, and from one supplier to many.
• Log every request and response for audit. "What exactly did we send and what did they say" is a question you'll be asked constantly.

Get the three-step flow and the B2B plumbing — markup, wallets, multi-tenancy — right, and Amadeus becomes a dependable engine you can build a real agency business on. Rush them, and you'll be reconciling mismatched fares and disputed wallet balances by hand for months. The API is the easy part; the portal around it is the product.

I've integrated Amadeus and other GDS suppliers into a live travel platform — search, pricing, booking, markup, agent wallets and refunds. If you're building a B2B travel portal, you can read more about my travel portal development work or get in touch.

Sometimes that's true. Usually it isn't. In most systems I've looked at, throwing more CPU and RAM at the problem just buys a few months and a bigger bill, because the real cause is still sitting in the code. Below is the order I actually work through when a SQL Server database has slowed to a crawl — roughly cheapest and highest-impact first.

1. Missing indexes — the number one culprit

An index is what lets the database jump straight to the rows it needs instead of reading the entire table. Without the right one, a query for a single customer might scan all two million rows every single time it runs. As the data grows, that same query goes from milliseconds to seconds, and the slowdown creeps up so gradually that no single day feels like the day it broke. Adding a well-chosen index can turn a multi-second query into an instant one, with no application changes at all.

2. The N+1 query problem

You load a list of 50 orders with one query, then — often without realising — the code fires off one more query per order to fetch its customer. That's 51 round trips to show a single page. With ORMs like Entity Framework it's especially easy to write by accident. The fix is usually to load the related data up front in one query instead of hundreds.

3. SELECT * and pulling back more than you need

When a query grabs every column and every row "just in case," the database has to read, transfer and materialise all of it. Asking only for the columns and rows you'll use — and paging large lists — cuts the work at the source.

4. Queries that can't use their indexes

Wrapping a column in a function, doing type conversions in the wrong place, or leading a search with a wildcard all quietly force the database to scan the whole table anyway. You find these by reading the execution plan — SQL Server's own explanation of how it ran the query.

5. Blocking and locking under load

If the app is fine when it's quiet and falls apart when everyone's using it, the problem may be queries getting in each other's way. When one operation holds a lock longer than it should, everything else queues up behind it.

6. Statistics and fragmentation

SQL Server decides how to run a query based on internal statistics. If those go stale, it starts making bad decisions. On a lot of the systems I inherit, routine maintenance was never set up, so performance degrades month after month for reasons nobody can see.

7. Only now: is it actually the hardware?

Sometimes the honest answer is yes. But by then you're making that decision with evidence instead of a guess. I've seen a "we need a bigger server" emergency turn out to be two missing indexes and one N+1 query — fixed in an afternoon, no new hardware.

A bigger server makes a slow query slow more quickly. It doesn't make it fast. The fix is almost always in the queries, not the hardware.

I'm Sunny Badgujar, a freelance full-stack .NET developer. I do SQL Server performance audits and query tuning for .NET applications. If your app is slow and you're not sure why, tell me what you're seeing.