title: “How Wego and Skyscanner Work End-to-End” category: Competitive Intelligence status: Complete created: 2026-02-25 related:

• “Wego Intelligence Report”
• “Wego Build Blueprint”
• “Supply Strategy — Aggregated Reference”

← Section Index · Master Index

How Wego and Skyscanner work end-to-end as flight meta-search platforms

Executive summary

Both Wego and Skyscanner operate primarily as meta-search engines (and increasingly as marketplaces) that aggregate flight offers from airlines and online travel agents (OTAs), normalize the returned itineraries/prices into a comparable results set, and then either handoff the traveler to a booking provider via a deeplink or (in Wego’s case for some inventory) complete checkout inside the Wego experience. Their “data aggregation” is therefore best understood as partner-supplied availability/pricing retrieval + normalization + ranking + tracked handoff, not as them “owning inventory” in the airline sense. citeturn1search9turn5search0turn0search0

Skyscanner’s public and partner documentation makes the partner-supply model explicit: flight prices/itineraries are provided by “booking agent/online travel agent partners,” and their flight integration relies on partner “Quote API” responses to obtain live price and availability. citeturn1search6turn5search9

Wego’s developer documentation is similarly explicit: Wego requires access to a partner API to query real-time availability and pricing, requires deeplinks, supports caching guidance, and uses click IDs plus pixels/reports for conversion visibility. citeturn5search0turn5search7

A crucial operational reality for both platforms is that flight prices are dynamic and can change between search and checkout; “accurate price before booking” flows (repricing/confirming with payment method and currency) are standard in airline distribution APIs and explain why meta-search products invest heavily in price accuracy controls, price refresh, partner quality scoring, and transparency. citeturn4search0turn4search1turn5search10turn1search13

How Wego works end-to-end

What Wego positions itself as (product surface)

Wego describes itself as a “travel metasearch engine and online marketplace” that lets travelers compare deals across hundreds of airlines and OTAs; Wego’s consumer site states that it compares fares across approximately 400 airlines and 150 OTAs, and also markets “700+ travel websites” in one search. citeturn0search0turn0search10

Key end-user features visible from Wego’s owned pages include:

• Fare Calendar to scan lowest fares across months, and logged-in Member Deals in some cases. citeturn0search1
• Surfacing of fare rules/inclusions (e.g., baggage, change/cancellation) before purchase. citeturn0search1
• A first-party checkout mode called “Book on Wego”, where the traveler can complete purchase without leaving Wego; Wego highlights localized payment methods and profile-based autofill as benefits. citeturn0search2turn0search1
• Wego also advertises “performance-driven placements” and broader advertising products, implying monetization beyond pure affiliate click-outs. citeturn3search16turn3search6

End-to-end user journey

At a systems level, Wego exposes two distinct booking handoff modes:

Mode A — Classic meta-search “redirect to provider”

1. User searches flights on Wego.
2. Wego returns results aggregated across providers (airlines/OTAs).
3. User selects an offer/provider and is redirected via a deeplink to the provider’s booking/summary page. citeturn5search0turn5search7
4. The provider completes booking; conversion is shared back to Wego via standard mechanisms (pixel, report, or GTM), linked to a click ID. citeturn5search7

Mode B — “Book on Wego” on-site / in-app checkout

1. User filters/selects “Book on Wego” options and checks out without leaving Wego. citeturn0search2turn0search1
2. Wego emphasizes localized payments and centralized booking management in the Wego profile. citeturn0search2

How Wego aggregates flight data and where it comes from

Wego’s provider integration requirements describe the aggregation mechanism directly: Wego needs access to a partner’s API to query real-time availability and pricing, and states it has integrated “a few hundreds” airline and OTA partners (and can work with “whatever flights API you have,” preferring JSON/XML). citeturn5search0

Wego’s spec shows what comes “from partners” into Wego’s aggregator:

• Itineraries with total price, currency, refundability flag, flight legs/segments, airline codes, timing, and (critically) deeplinkUrl/mobileDeeplinkUrl. citeturn5search0
• Partner guidance on caching: Wego asks partners how long results can be safely cached and states a default caching time (30 minutes) to reduce live queries. citeturn5search0
• Tracking requirements: Wego expects affiliate/tracking parameters inside deeplinks where needed. citeturn5search0turn5search7

Wego’s conversion tracking documentation shows how it closes the loop post-redirect: it uses a click identifier (e.g., wego_click_id) stored by the partner and returned via a conversion pixel/report, enabling Wego to record conversions and commissions. citeturn5search7

Wego’s “metasearch API” (evidence of internal aggregation model)

Wego’s affiliate developer documentation describes a search session + polling style workflow and explicitly states that “all available fares” for a trip come from different OTAs and airlines (i.e., multi-provider aggregation). citeturn5search8

Wego also positions its developer portal as a multi-sided marketplace:

• “Affiliates” can integrate flights/hotels comparison via marketplace APIs.
• “Distribution” can syndicate “Book on Wego” inventory.
• “Providers” (hotels/airlines/suppliers) can publish inventory to reach Wego travelers. citeturn3search1

Wego end-to-end flow diagram (conceptual, based on Wego docs)

flowchart LR
  U[Traveler] --> S[Wego Search UI]
  S --> A[Wego Aggregation Layer]

  A --> P1[Airline / OTA Partner APIs]
  A --> P2[Airline / OTA Partner APIs]
  P1 --> A
  P2 --> A

  A --> R[Rank + Normalize Results]

  R -->|Option 1| D[Deeplink to Partner Checkout]
  D --> B[Partner Booking]
  B --> CT[Conversion Tracking: click_id + pixel/report/GTM]

  R -->|Option 2| W[Book on Wego Checkout]
  W --> BO[Booking Confirmed + Stored in Profile]

This architecture is directly implied by Wego’s requirements for partner real-time pricing APIs, deeplinks, caching guidance, plus conversion tracking mechanisms. citeturn5search0turn5search7turn0search2

Practical “where does Wego’s data come from” summary table

How Skyscanner works end-to-end

What Skyscanner positions itself as (product surface and monetization)

Skyscanner’s consumer help pages state it is free to search and that it searches over 1,200 travel providers; when it refers a user to book, “they pay us a small fee.” citeturn1search8

Skyscanner’s “How Skyscanner works” article similarly explains:

• Skyscanner searches “billions of prices” from “hundreds of providers.”
• Travelers typically book directly with the provider.
• Providers “usually pay” Skyscanner a commission/referral fee, and Skyscanner does not pass that on to the user.
• Results are not exhaustive because Skyscanner does not compare all providers in the market. citeturn1search9

End-to-end user journey (flight search to booking handoff)

Skyscanner’s partner developer documentation describes the internal mechanics used on its own site for flight search:

1. User initiates a flight search.
2. Skyscanner uses a create + poll workflow for its live pricing:
   • /create returns an initial subset quickly to reduce “time to first result.”
   • /poll continues retrieving results; the backend “makes calls to our full list of supply partners for inventories,” and the UI progressively fills in results. citeturn5search10turn1search1
3. User selects an itinerary/pricing option and follows a deeplink/redirect to a booking provider website. citeturn1search9turn5search2

Skyscanner’s developer docs also surface post-processing dimensions that affect user trust:

• It distinguishes booking “transfer types” and warns about self-transfer and protection levels (e.g., managed vs protected self-transfer), implying Skyscanner normalizes itinerary semantics and adds user-facing disclosures. citeturn5search2

How Skyscanner aggregates flight data and where it comes from

Skyscanner is unusually transparent in partner documentation about the aggregation layer:

• Its Flights API content is derived from “supply partners (airlines and online travel agents).” citeturn3search2turn3search11
• It explicitly states that prices are provided by booking agent/OTA partners and are “subject to change without notice.” citeturn1search6
• For integrations with suppliers/OTAs, Skyscanner’s “Quote API” documentation states that the Quote API is “the way we obtain live price and availability information from your server.” citeturn5search9

This is the core answer to “where does Skyscanner get data”: Skyscanner gets live price and availability from partner systems (airlines and OTAs) that expose quote/availability endpoints. citeturn5search9turn3search2

Skyscanner’s caching layer (exploratory / indicative pricing)

Skyscanner separates “exploratory” pricing from “bookable” live pricing:

• The Indicative Prices API returns the cheapest prices “seen last” and is cached (up to ~4 days), explicitly positioned as faster but less accurate than live prices—useful for flexible/low-intent exploration (e.g., when travelers don’t know destination/date). citeturn1search0
• This cache is populated based on lowest prices seen for a route/date, updated as travelers search. citeturn1search0

Skyscanner’s tracking and affiliate plumbing

Skyscanner’s developer documentation for tracking states it partners with entity[“company”,“Impact”,“partner marketing platform”] to track traffic and pay affiliates a share of commission; it also warns against including PII in tracking parameters. citeturn5search3turn5search5

Skyscanner’s trust and “data enrichment” layers

Skyscanner operates additional data loops that influence ranking and conversion:

• Quality Rating Score: Skyscanner explains it collects traveler feedback after the user visits a provider site and combines it with post-booking feedback received by support; it uses the last 91 days of feedback and refreshes weekly. citeturn1search13
• Emissions labeling: Skyscanner shows emissions info when a flight is estimated to emit at least 6% less CO2e than typical on the route; emissions data is powered by the Travel Impact Model and sourced/distributed by coalition partners of entity[“organization”,“Travalyst”,“sustainable travel coalition”]. citeturn1search14
• Travel Insight (Skyscanner data product): Skyscanner states it collects data from every search and redirect on its app/website across many data points, and that it does not collect personal data; it frames redirect data as representative of bookings. citeturn0search9

Skyscanner end-to-end flow diagram (conceptual, based on Skyscanner docs)

flowchart LR
  U[Traveler] --> UI[Skyscanner Search UI]

  UI --> C[Live Prices: /create]
  C --> R0[Initial Cached Subset]

  UI --> P[Live Prices: /poll session]
  P --> SP[Calls to Supply Partners: airlines + OTAs]
  SP --> P --> R[Normalized Results + Sorting/Filters]

  R --> DL[Redirect/Deeplink to Provider]
  DL --> B[Provider Booking + Checkout]

  R --> Q[Optional: Price Refresh / Reprice]

This flow is directly supported by Skyscanner’s description of /create and /poll, and its statement that polling involves calls to its supply partners. citeturn5search10turn1search1turn3search2

Practical “where does Skyscanner’s data come from” summary table

How meta-search flight “data aggregation” really works under the hood

This section connects what Wego and Skyscanner publish to the broader airline distribution stack, to answer the implied question: Where does the partner’s data come from?

The upstream inventory chain: airlines, OTAs, GDS, and NDC

Meta-search platforms typically integrate with:

• Airlines directly, increasingly through NDC or airline retailing APIs.
• OTAs/booking agents, who themselves source inventory from multiple places: traditional GDSs, direct airline connections, and NDC aggregators.

flowchart TD
    Traveler -->|Searches| MetaSearch[Meta-Search (Wego/Skyscanner)]
    MetaSearch -->|Queries API| OTA[Online Travel Agency]
    MetaSearch -->|Queries API| AirlineDirect[Airline Direct (NDC/API)]
    
    OTA -->|Sourcing| GDS[Global Distribution System (Amadeus/Sabre)]
    OTA -->|Sourcing| NDCAggregator[NDC Aggregator (Duffel/Travelfusion)]
    OTA -->|Sourcing| AirlineDirect
    
    GDS --> AirlineInventory[Airline Offer & Order Management]
    NDCAggregator --> AirlineInventory
    AirlineDirect --> AirlineInventory

The New Distribution Capability (NDC) is a standard launched by IATA; IATA describes it as an XML-based data transmission standard designed to improve airline offer distribution (richer content, transparency, product differentiation) and is open to third parties to implement.

So, even when “Wego/Skyscanner get data from OTAs and airlines,” the “true origin” of the fare can be:

• Airline inventory systems (offer/order management),
• Or GDS-published fares and availability,
• Or NDC-derived offers with richer ancillaries.

Why price mismatch happens (and why both platforms require “final price” behavior)

Both Wego and Skyscanner brand around transparent/all-in pricing, and both specify technical requirements around returning the “final price payable” and handling fast responses; this is a direct consequence of airline pricing dynamics:

• Wego requires partners to return price objects and deeplink to the exact offer; it also asks for caching guidance and payment charge data. citeturn5search0
• Skyscanner requires partners’ Quote API to return a final price matching the provider website (and do so quickly), and acknowledges prices are provided by partners and can change. citeturn5search9turn1search6

Official airline distribution APIs reinforce that repricing/confirming is standard:

• **entity[“company”,“Amadeus”,“travel technology company”] documents a canonical flow where “Flight Offers Price” confirms the final price and availability (including taxes and fees) before booking. citeturn4search0
• **entity[“company”,“Duffel”,“flight booking api company”] documents that the payment method can impact final price (e.g., card surcharges or currency differences) and provides “price before booking” workflows to ensure customer price transparency. citeturn4search1turn4search8

Reference data (airport/airline codes)

Codes used through these systems are standardized; IATA markets its Airline Coding Directory and Location Identifiers as the “only official source” for airline and location codes and an operational dependency for travel systems. citeturn4search6

Practical takeaways for building a similar aggregator

Wego and Skyscanner’s published partner requirements strongly imply a set of “non-negotiable” design choices for any flight meta-search platform.

Aggregation workflow patterns that appear “standard” in both ecosystems

Asynchronous search sessions and progressive result completion.
Skyscanner explicitly uses create/poll because supply partners return inventory at varying speeds; Wego’s affiliate API also references triggering a search session and polling for results. citeturn5search10turn5search8

Strict deeplink discipline.
Wego’s provider spec makes deeplink URLs a primary artifact of each returned itinerary; this is what monetizes the meta-search click-out. Skyscanner’s booking types documentation similarly presents deep links as part of pricing options. citeturn5search0turn5search2

Closed-loop measurement through click IDs and conversion reporting.
Wego documents “wego_click_id” and multiple conversion reporting modes; Skyscanner documents Impact-based tracking and parameter rules (including PII constraints). citeturn5search7turn5search3

Managing price accuracy as a product and marketplace quality problem.
Skyscanner’s quality rating emphasizes price accuracy and fee transparency as core dimensions; Wego emphasizes all-inclusive pricing and also captures payment charges in partner requirements. citeturn1search13turn5search0turn0search1

Where “defensibility” tends to emerge

Skyscanner’s Travel Insight description shows how meta-search platforms can build defensibility by storing high-scale search + redirect event data (route/date/device/price, etc.) for forecasting and market intelligence—an advantage that improves ranking, personalization, and even creates sellable data products. citeturn0search9

Wego’s developer portal positioning (“Affiliates / Distribution / Providers”) and “Book on Wego” suggests another defensibility path: evolving from click-out meta-search into a marketplace with partial first-party checkout, while still leveraging broad partner supply. citeturn3search1turn0search2