Skyscanner: Flight Discovery, Live Prices and Booking Handoff

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 covers the car-rental profile.

Use the flight API integration guide 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 ↗ describes search and content products for partner applications. The affiliate programme ↗ offers referral products and a separately reviewed commercial relationship.

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 ↗ 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 ↗ 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:

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 ↗ 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

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 to translate these decisions into adapters and session handling.