---
title: "Skyscanner: Flight Discovery, Live Prices and Booking Handoff"
description: "Choose Skyscanner live or indicative flight data, preserve itinerary and seller identity, and diagnose price, polling and booking-handoff failures."
slug: "skyscanner"
translationKey: "platform-skyscanner"
locale: "en"
type: "profile"
category: "flight-metasearch"
platform: "Skyscanner"
domain: "skyscanner.com"
tags: ["skyscanner","flight","api","live-prices","indicative-prices","car-rental"]
vertical: ["flight","hotel","car-rental"]
featured: true
publishedAt: "2026-09-19"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
directory: {"platformType":"metasearch","roles":["metasearch","comparison-engine","travel-marketplace"],"ecosystemLayers":["retail-discovery"],"turkeyRelevance":"active-market","status":"active","audiences":["b2b","b2c"],"reviewedAt":"2026-09-26","businessModels":["affiliate"],"integrationMethods":["api","deep-link"],"docsUrl":"https://developers.skyscanner.net/docs/intro","guideTranslationKey":"integration-skyscanner-flight-api","directSupplierParticipation":"yes","developerDocsAvailable":"yes","sources":[{"title":"Skyscanner Travel APIs","url":"https://developers.skyscanner.net/docs/intro"},{"title":"Skyscanner affiliate programme","url":"https://www.partners.skyscanner.net/product/affiliates"}]}
sources:
  - title: "Skyscanner Travel APIs"
    url: "https://developers.skyscanner.net/docs/intro"
  - title: "Skyscanner affiliate programme"
    url: "https://www.partners.skyscanner.net/product/affiliates"
  - title: "Flights Live Prices overview"
    url: "https://developers.skyscanner.net/docs/flights-live-prices/overview"
  - title: "Flights Indicative Prices overview"
    url: "https://developers.skyscanner.net/docs/flights-indicative-prices/overview"
  - title: "Flights price refresh"
    url: "https://developers.skyscanner.net/docs/flights-live-prices/refresh-prices"
---

Skyscanner combines travel discovery, price comparison and partner handoff. Its developer portal separates flight, hotel and car-hire products. This profile focuses on flight-search decisions; [Skyscanner Cars](/en/metasearch/car-rental/skyscanner-cars) covers the car-rental profile.

Use the [flight API integration guide](/en/integrations/skyscanner-flight-api) for authentication, request/response models and polling implementation. Here the focus is choosing the right data product, preserving offer meaning and diagnosing the journey from discovery to booking.

## Production scenario: an attractive fare disappears

Imagine a fictional fare calendar showing EUR 90. A traveler selects a date for two adults with checked baggage, then sees EUR 260 in a live search. Treating this as a single price-accuracy incident hides several possible differences: historical estimate versus current offer, one traveler versus two, and baggage excluded versus included.

Record the data product, observation time, passenger composition, itinerary, selling agent, currency and included services before comparing totals. A discovery quote should not silently become a promise of a bookable family fare.

## Choose the relationship before the API

The [Travel APIs introduction](https://developers.skyscanner.net/docs/intro) describes search and content products for partner applications. The [affiliate programme](https://www.partners.skyscanner.net/product/affiliates) offers referral products and a separately reviewed commercial relationship.

| Product decision | Boundary to confirm |
|---|---|
| Send readers to Skyscanner using referral links | Affiliate acceptance, attribution and permitted placement |
| Build search inside your own application | API access, supported products and usage conditions |
| Advertise your own airline or agency inventory | Supplier partnership requirements; do not assume a search API publishes inventory |

An affiliate payout is not a universal percentage of the ticket price. Verify the applicable agreement and reporting basis. Likewise, documentation listing an API does not establish your account's entitlement to it.

Keep booking ownership explicit. In a provider-handoff journey, the selected seller handles checkout and subsequent order servicing. A successful search response or outbound click does not establish a confirmed booking or issued ticket.

## Live and indicative prices serve different decisions

The [Indicative Prices overview](https://developers.skyscanner.net/docs/flights-indicative-prices/overview) describes cached estimates for exploration, based on one adult in economy. Use that product for discovery with clear price context, then request a live search for the selected journey.

The [Live Prices overview](https://developers.skyscanner.net/docs/flights-live-prices/overview) describes create/poll sessions and incremental results. Live search can initially return cached partial data; “live” should not be presented as a guarantee that every displayed offer has just been reconfirmed.

Choose a progressive experience deliberately. Show useful early results while retaining search status. Do not report an unfinished session as complete or discard late results merely because the first page already rendered.

## Preserve itinerary and seller identity

A useful internal model separates the journey from the commercial option selling it:

| Internal concept | Preserve for comparison |
|---|---|
| Itinerary and legs | Outbound/return structure and dates |
| Segments | Airports, departure/arrival times and connections |
| Carrier roles | Marketing and operating carrier where available |
| Fare conditions | Cabin, fare brand, baggage and change/refund terms where available |
| Pricing option | Agent, amount, currency and booking destination |
| Search context | Passenger mix, supported request parameters and observation time |

This is an internal modeling recommendation, not a complete provider schema. Do not infer missing baggage as zero allowance or treat the same flight number as the same offer. Preserve unknown values so the interface can communicate uncertainty.

Keep source identifiers scoped to their documented lifecycle. A search-session entity should not automatically become a permanent catalog identity. Distinguish airport and city selection, local departure dates and overnight arrival when investigating apparent duplicates.

## Refresh and handoff

The [refresh-prices documentation](https://developers.skyscanner.net/docs/flights-live-prices/refresh-prices) provides a selected-itinerary refresh flow. Evaluate it before handoff according to the current integration requirements and the age of the result. Refresh is an observation of an offer, not a seat reservation.

Retain the selected agent and supported deep link rather than reconstructing a generic seller URL. Test clean-session and mobile landings. If the fare changes or disappears, explain the new state and require a fresh selection; silently substituting another seller or itinerary breaks the user's decision.

## Failure modes and recovery

| Symptom | First check | Recovery decision |
|---|---|---|
| Calendar fare differs from search | Indicative/live context and passenger basis | Explain estimate; use a matching live search |
| Cheapest result disappears after polling | Merge/replacement behavior and entity references | Apply documented response semantics |
| Search never finishes | Session state, errors and local polling budget | Stop bounded work and expose incomplete status |
| Wrong airport opens after click | City/airport identity and selected option | Repair mapping or handoff |
| Price agrees but baggage differs | Fare and ancillary information | Treat offers as non-equivalent |
| Many duplicate bookings in analytics | Click events versus confirmed order evidence | Separate funnel events and reconcile |

Use bounded polling and account-appropriate limits. Stop work for abandoned searches, and keep a retry from creating unbounded new sessions. These are engineering controls, not fixed Skyscanner timeout or quota values.

## Operational metrics and production checklist

Measure time to first useful result separately from time to completion. Track completed sessions divided by valid started sessions, with user abandonment reported separately. Measure poll requests per active session and errors by class to identify wasted capacity.

For handoff quality, divide equivalent successful landing samples by eligible tested clicks. Segment price differences by data product, result age, passenger mix and agent. Count booking outcomes only where the agreed reporting supplies that evidence; clicks are not tickets.

Test a partial result followed by replacement, expired session, changed fare, missing baggage information, airport/city ambiguity and failed deep link. Confirm each case has an observable state and an owner.

The linked official documentation defines supported behavior. The diagnosis tables, metrics and release checks are engineering recommendations, not provider SLAs. Continue with the [implementation guide](/en/integrations/skyscanner-flight-api) to translate these decisions into adapters and session handling.