GDS vs OTA vs Travel Metasearch
Understand how GDSs, OTAs and metasearch differ, where each sits in travel distribution, and how inventory reaches travelers.
GDSs, OTAs and metasearch products all participate in travel distribution, but they create value at different layers.
Treating them as one generic type of travel site makes architecture harder to understand.
What is a GDS?
GDS means Global Distribution System. Historically, it provides a technology layer connecting airline inventory and travel-agency distribution. Amadeus, Sabre and Travelport are well-known names in this space.
A GDS is not a consumer metasearch website.
What is an OTA?
An Online Travel Agency exposes inventory to travelers and can own a significant portion of the booking transaction. Booking.com, Expedia and Agoda are common examples.
What is metasearch?
Metasearch compares selling sources and routes the traveler to a selected provider. Metasearch is the comparison and traffic-routing layer: it aggregates offers from multiple providers, normalizes them for a search context and usually hands the traveler off to the selected seller.
Google Flights, Skyscanner, KAYAK and trivago are examples.
Simplified chain
One flight-distribution path might look like: Airline → GDS/NDC/Aggregator → OTA → Metasearch → User But not every booking uses every layer. Direct airline APIs or NDC connections can bypass parts of the chain.
Who owns the transaction?
- GDS: distribution infrastructure,
- OTA: seller/intermediary,
- metasearch: comparison and traffic routing.
That ownership difference shapes contracts and economics.
Why it matters
A travel-tech data model may need explicit provider roles such as airline, hotel, wholesaler, GDS, OTA, metasearch and booking engine. That makes lineage and unit economics much easier to analyze.
Conclusion
A GDS is distribution infrastructure, an OTA is a transaction intermediary and metasearch is a comparison layer. Real travel-distribution architectures can combine them in different ways.
Data ownership across the chain
The most useful architecture question is not “which platform supplied the data?” but which layer owns which state?
In flights, for example:
- airline: schedule, inventory and fare source,
- GDS/NDC aggregator: distribution contract and normalized access,
- OTA: shopping, markup/commission, checkout and booking ownership,
- metasearch: comparison, ranking, provider handoff and acquisition measurement.
When these boundaries are unclear, the same fare is transformed by multiple business-rule layers with inconsistent results.
Economics change by layer
GDSs can introduce distribution/segment economics; OTAs deal with markup, commission and payment economics; metasearch often operates around CPC, CPA or referral models. The cheapest supplier is therefore not automatically the most profitable channel.
A useful OTA cost model separates supplier/net cost, distribution cost, payment cost, acquisition cost, cancellation/refund cost and gross margin.
Booking and servicing ownership
After a flight booking is created, ticketing, servicing, exchange/refund and disruption handling may remain with different parties. Metasearch typically hands the transaction downstream. OTAs more often own a larger part of the customer-service lifecycle.
That difference makes “who am I buying from?” an important UX and data-model field.
Architecture anti-pattern
Putting airlines, GDSs, OTAs and metasearch engines into one undifferentiated provider role leads to poor lineage, duplicate inventory, incorrect attribution and unclear support ownership. A stronger model separates entity from role so that the same company can act as supplier, seller or traffic source in different contexts.
Useful KPIs
Track supplier availability/latency/error rate, OTA look-to-book/conversion/margin, metasearch CTR and acquisition economics, handoff success/price mismatch, and post-booking cancellation/servicing cost.
MetaSearch 101 interpretation
The clearest way to separate GDS, OTA and metasearch is through inventory ownership → transaction ownership → traffic ownership, not through brand labels.
Separate source-of-truth boundaries
GDS, OTA and metasearch may appear in the same funnel but they do not own the same state.
Supplier / CRS / PMS
|
v
GDS / Connectivity / Wholesaler
|
v
OTA / Direct Booking / Distribution Channels
|
v
Metasearch / Discovery
|
v
TravelerTopology varies by provider. The important design question is which system is authoritative for identity, price, availability and booking state.
Why do data contracts differ by layer?
- GDS/distribution: availability, fare/rate, reservation capability.
- OTA: merchandised offer + transaction.
- Metasearch: comparable offer + handoff.
- Booking engine: final booking context + payment/confirmation.
The same field named “price” can have different semantics across these layers.
Common failure modes
- metasearch treats an OTA as raw supplier and creates duplicate supply,
- GDS fare and NDC offer are normalized incorrectly,
- booking state reaches metasearch too late,
- hotel content is current in one channel and stale in another,
- source ID is used as canonical identity.
Architecture questions
- Where is inventory truth?
- Who calculates price?
- Who owns booking?
- Which system publishes cancellation?
- Where is canonical identity managed?
- At which hop does commercial attribution begin?
Separate roles by state ownership, not by industry labels alone.
Planning a similar integration?
We can review requirements, feed/API design and the production approach with you.