How to Build an App Like Expedia: Travel Aggregation, APIs, and Real Costs

You are not building an airline. You are not building a hotel chain. Expedia does not own a single seat or a single room. What Expedia built is a search engine and booking layer that sits on top of inventory owned by thousands of airlines and hotels. That distinction matters because it changes what you actually need to build.

The inventory problem is solved by APIs. The hard problems are pricing freshness, search performance, checkout reliability, and itinerary management. This guide covers exactly those things.

What Expedia actually is

Expedia Group operates multiple travel brands -- Expedia, Hotels.com, Vrbo, Orbitz, Travelocity -- but the core product is the same across all of them: a meta-search and booking engine that aggregates inventory from suppliers and presents it in a unified search experience.

Expedia does not set flight prices. Airlines do. Expedia shows you those prices and earns a commission when you book. For hotels, Expedia negotiates net rates (lower than public rates), marks them up, and keeps the difference. Or it earns a commission on the hotel's published rate.

This means when you build an Expedia-like platform, you are building:

1. A connection layer to supplier APIs (flights, hotels, cars)
2. A search and filtering interface on top of that inventory
3. A checkout flow that processes bookings through the supplier
4. An itinerary management system that tracks bookings across suppliers
5. A user account layer for saved preferences and booking history

You are not building the inventory. You are building everything around it.

The API decision: Do not build from scratch

The single most important decision in a travel platform is which inventory APIs you use. Getting this wrong adds months of delay and thousands in unnecessary API costs.

Flights

Amadeus: The largest GDS (Global Distribution System) travel data provider. Amadeus covers 400+ airlines and gives you real-time availability, pricing, and booking. The API is comprehensive but has a learning curve -- their sandbox environment requires setup time and their documentation assumes you already know GDS concepts. Cost: per-search query charges in production, plus a commission or markup model on bookings. Best for platforms that want full carrier coverage.

Duffel: A modern flight API that sits on top of airline NDC (New Distribution Capability) connections. Cleaner developer experience than legacy GDS, faster to integrate, supports ancillaries (seat selection, bags) natively. Coverage is narrower than Amadeus but growing. Cost: per-booking fee. Best for teams that want faster time to market and can accept slightly narrower airline coverage in v1.

Sabre and Travelport: Enterprise-grade GDS alternatives to Amadeus. Higher integration complexity, typically require a formal partner agreement and longer sales cycles. Use these if you are targeting corporate travel or need specific carrier access not available on Duffel.

For most v1 builds, Duffel is the right starting point for flights. You can migrate to Amadeus later when you have booking volume that justifies the GDS relationship.

Hotels

Booking.com Demand API: Access to Booking.com's 28 million+ property inventory. You search their inventory, display their properties, and earn an affiliate commission on completed bookings. Rates are live. The API is well-documented. Booking.com handles the actual reservation with the property.

Expedia Partner Solutions (EPS): Similar to Booking.com's demand API -- access to Expedia Group's hotel inventory at affiliate commission rates. Good coverage in North America and Europe.

Hotelbeds: A wholesale hotel beds aggregator with strong coverage in Europe, Caribbean, and APAC. Works on a net rate model -- you buy inventory below public prices and markup to customers.

Direct hotel chain APIs: Marriott, Hilton, IHG, and Hyatt all have direct booking APIs for affiliates. Higher commission rates than generic aggregators, but limited to that chain's properties.

For v1, pick one: Booking.com Demand API or EPS. They give you broad coverage without requiring direct hotel relationships. Once you have transaction volume, you can negotiate direct rates with specific hotel groups.

Core features for v1 -- build only these

1. Search with filters

Flight search: origin, destination, date(s), number of passengers, cabin class. Results sorted by price with filters for stops, airline, departure time, and duration.

Hotel search: destination, check-in/check-out dates, number of guests. Results sorted by price or rating with filters for star rating, amenities, cancellation policy, and neighborhood.

Keep the filter set minimal in v1. Expedia has 40+ hotel filters. Your v1 needs 6-8 that actually drive decisions: price, rating, free cancellation, distance from city center, breakfast included, and property type.

2. Pricing calendar

A 30-day price calendar showing cheapest available fares by date. This is one of Expedia's highest-engagement features -- users often shift travel dates by 1-2 days to save money. For flights, this requires querying the API for each date and caching results. Build with short TTLs (5-10 minutes for flights, 30-60 minutes for hotels) to balance freshness vs. API cost.

3. Checkout and booking confirmation

The booking flow: passenger/guest details, payment, booking confirmation, and email confirmation with booking reference. This is where most errors happen -- API timeouts, price changes between search and checkout (price is not guaranteed until booking is confirmed with the supplier), and payment gateway failures.

Design the checkout to handle errors explicitly. If the price changed between the search results page and the booking confirmation, tell the user clearly and let them accept the new price or go back. Do not silently fail.

4. Booking management

Users need to view, download, and (where the supplier allows) cancel or change their bookings. This is harder than it sounds because every airline has different cancellation rules, different APIs for change requests, and different refund timelines. For v1, support view and cancel for bookings made on refundable fares. Handle change requests via customer support in v1 -- do not build a self-serve change flow until you understand the airline API error cases.

5. User account and itinerary dashboard

A logged-in user sees all their upcoming and past trips in one place. A trip may have multiple bookings -- an outbound flight, a return flight (separate booking reference on some airlines), and a hotel. The itinerary dashboard aggregates these by travel date. This requires a solid data model: trips as containers, bookings as line items under a trip, each booking linked to a supplier booking reference.

The GDS/API layer: What you are actually connecting to

When you search Expedia for a flight from New York to London, here is what happens in milliseconds:

1. Expedia sends a search query to one or more inventory sources (Amadeus, airline NDC connections, etc.)
2. Those sources return available flights and prices
3. Expedia aggregates, deduplicates, and ranks results
4. You see the results page

This sounds simple. The complexity is in step 2-3: different sources return different data formats, prices may differ across sources for the same flight, ancillary availability (bags, seats) comes from a separate API call, and the prices returned are not guaranteed -- they are indicative until you start the booking transaction.

When you use Duffel or Amadeus, they handle most of this aggregation for you. What you still need to handle: response normalization (mapping their data model to your UI), error handling (API timeouts, no-results scenarios, invalid fare class codes), and caching strategy.

The hardest engineering problems

Real-time pricing and caching

Flight prices change every few seconds. Hotel rates change by channel and time of day. If you cache prices too long, users hit price mismatches at checkout -- the price you showed them is no longer available. If you do not cache at all, every page interaction triggers an expensive API call and your search feels slow.

The right architecture is a two-layer cache:

• Search results cache: Cache the full results page for a specific search query for 2-5 minutes. If the user searches JFK-LHR on November 15, cache those results. Refresh when the cache expires.

• Price guarantee window: When a user selects a specific flight and moves to checkout, fetch a fresh price from the API. If the price changed from what you showed on the search page, surface that to the user before they enter payment details.

Redis is the standard cache layer here. Set TTLs based on how volatile prices are for each vertical -- shorter for flights (60-120 seconds), longer for hotels (5-15 minutes).

Search performance with large result sets

An Amadeus flight search for a busy route returns hundreds of results: different airlines, stopover combinations, cabin classes, and fare families. Filtering and sorting 500+ results in the browser is slow. You need to do result processing server-side before sending to the client.

Server-side: filter results to a reasonable set (top 100-150 by price, filtered by user's active filters). Client-side: sort and re-filter from that set as the user adjusts filters.

For hotel search, Elasticsearch is worth adding from the start if you are pulling inventory from multiple sources. It handles faceted search (multi-select amenity filters, price range sliders, geospatial sorting) efficiently at scale.

Itinerary management across multiple bookings

A user books a round-trip flight on American Airlines (two separate booking references if outbound and return are priced separately), then books a hotel at a Hilton via Booking.com (a third booking reference). All three belong to the same trip.

Your itinerary data model needs:

• Trip: a container with travel dates and a destination

• Booking: a line item under a trip, with a supplier name, booking reference, booking status, and trip dates

• Booking status sync: a background job that polls the supplier API (or handles webhooks where supported) to update booking status when airlines confirm, tickets are issued, or cancellations are processed

The status sync is where many first-builds break. The supplier confirms the booking, but the confirmation email arrives 10 minutes later after ticket issuance. Your system needs to handle the pending-to-confirmed state transition cleanly so users do not see confusing status messages.

Cancellation and change flows

Airlines have some of the most complex business rules in any industry. A refundable fare has a refund window. A semi-flexible fare allows changes for a fee. A basic economy fare allows no changes and no refund. Each airline implements these rules differently in their API.

For v1, this is how to handle it: only allow self-serve cancellation for bookings where the fare is marked as fully refundable in the API response. For everything else, direct users to customer support. This keeps your cancellation logic simple and prevents you from accidentally processing cancellations that the airline will reject.

Add self-serve change flows in v2, after you have mapped the error cases for the specific airlines in your market.

Tech stack

What to skip in v1

Do not build these in v1. Each one is a substantial engineering project that adds cost and time before you have validated demand.

• Package deals (flight + hotel bundled): requires coordinating availability across two APIs simultaneously, complex pricing logic, and a different cancellation policy

• Car rentals: another API integration (Rentalcars, QEEQ) with its own data model and cancellation rules

• Activities and experiences: Viator API or GetYourGuide API -- a third content type with different booking windows

• Loyalty points: requires a points ledger, earn/burn rules, and integration with airline frequent flyer programs

• Personalized recommendations: meaningful personalization requires booking history data you do not have yet

• Cruise search: a niche inventory source with its own API providers

Build the flight or hotel booking loop end to end. Get real users booking real trips. Then add the second vertical.

Cost to build

Monthly API costs once live: $2K-$15K depending on search volume and booking conversion, covering GDS query fees, mapping API calls (for hotel location display), and payment processing. Budget these as a percentage of gross booking value, not a fixed monthly cost.

The business model

Travel platforms earn money three ways:

Commission: You pass the booking through at the supplier's rate and earn a percentage (typically 5-15% for hotels, 1-3% per flight segment on GDS).

Markup on net rates: You negotiate wholesale (net) rates from hotel groups or wholesalers like Hotelbeds, then mark up and sell at your own price. Higher margin but requires upfront supplier relationships.

Subscription (B2B white-label): You build the travel booking engine and license it to corporate travel programs, HR platforms, or employee benefit tools. Monthly SaaS fee rather than per-booking commission.

For a consumer travel startup, start with commission. Markup models require minimum volume commitments that are hard to hit before you have users.

How RaftLabs approaches this

Most founders come to us wanting to build "an Expedia competitor." We redirect that conversation immediately. Expedia has 30 years of supplier relationships and $11B in annual revenue. You cannot beat them on breadth.

What you can beat them on is focus. A travel platform for adventure travelers that deeply integrates with activity providers and boutique lodges. A corporate travel tool that integrates with expense management software. A family travel platform that handles the complexity of booking travel for kids across airlines with different lap-infant policies.

The product architecture follows from the niche. Which APIs do you connect to? What does the search UI optimize for? What does the itinerary view show?

We build the GDS integration, the price caching layer, and the booking management flows alongside the search UI -- not after it. You cannot test real travel booking without live API data.

If you want to scope the build for your specific travel product concept, start with a scoping call.