Google Flights Partner Integration: Live API & Price Feed Developer Guide

A Google Flights integration should not be treated as a public flight-search API. Partner participation is onboarding-controlled, and the public documentation exposes three important pricing modes:

• Live API — Google Flights Search sends queries to a partner endpoint.
• Price Feed — partners provide flight/price data to Google.
• Price Through Google — Google computes pricing through its own pricing sources.

So the first architecture question is not “which public endpoint do I call?” but which partner integration mode am I implementing?

For partner access, fare equivalence and booking ownership, see the Google Flights profile. This guide focuses on implementation boundaries.

1. Separate public APIs from partner integration

There is no general-purpose public Google Flights search endpoint comparable to a normal developer search API.

Keep the partner contract behind an adapter:

Google Flights
    |
    v
Partner Integration Adapter
    |
    +--> Live API endpoint
    +--> Price Feed exporter
    +--> Booking-link generator
    +--> Quality / analytics ingestion
    |
    v
Canonical Flight Domain

2. Live API flow

Google's Travel Analytics documentation explicitly describes Google Flights Search sending queries to partner API endpoints.

Google Flights search
        |
        v
Partner Live API
        |
        v
availability + pricing
        |
        v
Google Flights booking options
        |
        v
partner booking page

Public reporting also shows one-way and round-trip support for Live API integrations, plus response-time and timeout diagnostics.

3. Internal request model

The actual partner wire schema can be part of onboarding. Your internal contract should remain provider-neutral.

interface FlightPricingRequest {
  userCountry?: string;
  tripType: "one_way" | "round_trip";
  origin: { airportCode: string };
  destination: { airportCode: string };
  outboundDate: string;
  returnDate?: string;
  passengers: {
    adults: number;
    nonAdults: number;
  };
  cabinClass?:
    | "economy"
    | "premium_economy"
    | "business"
    | "first";
  currency?: string;
}

Google partner request
    -> validate
    -> internal pricing request
    -> pricing engine
    -> canonical solution
    -> Google serializer

4. Internal response model

interface FlightPricingResponse {
  requestId: string;
  solutions: FlightSolution[];
  generatedAt: string;
}

interface FlightSolution {
  itinerary: FlightItinerary;
  bookingOptions: FlightBookingOption[];
}

interface FlightBookingOption {
  providerId: string;
  price: {
    amount: number;
    currency: string;
  };
  deeplink: string;
  available: boolean;
}

5. Itinerary model

Google Flights quality datasets expose concepts such as slices, segments, marketing carriers, operating carriers, validating carrier and trip type.

interface FlightItinerary {
  slices: FlightSlice[];
  validatingCarrier?: string;
}

interface FlightSlice {
  segments: FlightSegment[];
}

interface FlightSegment {
  origin: string;
  destination: string;
  departure: string;
  arrival: string;
  marketingCarrier?: string;
  operatingCarrier?: string;
  flightNumber?: string;
}

Do not collapse marketing and operating carriers.

6. Price Feed

A Price Feed integration provides flight and price data to Google ahead of query-time.

interface FlightPriceFeedRow {
  itineraryKey: string;
  origin: string;
  destination: string;
  departureDate: string;
  returnDate?: string;
  cabinClass?: string;
  price: number;
  currency: string;
  bookingUrl: string;
  generatedAt: string;
  expiresAt?: string;
}

Key rule:

feed accepted != price still valid

7. Price Through Google

Google documents GDS-based and web-fare-based Price Through Google sources.

Architecture questions:

Who computes the price?
Who owns availability?
Who owns booking-link quality?
Who owns final price reconciliation?

8. Booking-link contract

The booking option should preserve itinerary and commercial context.

interface GoogleFlightsHandoff {
  itineraryKey: string;
  providerId: string;
  displayedPrice: number;
  currency: string;
  deeplink: string;
  referralId?: string;
}

A generic homepage redirect is poor link quality.

9. Price and link quality

Two core public Google Flights quality metrics are:

• Itinerary Not Found
• Price Discrepancy

Useful internal taxonomy:

ITINERARY_NOT_FOUND
PRICE_MISMATCH
CURRENCY_MISMATCH
FARE_UNAVAILABLE
DEEPLINK_BROKEN
WRONG_PASSENGER_CONTEXT
WRONG_CABIN
STALE_PRICE
UNKNOWN

10. Live API latency

Google's Live API Performance reporting includes:

• query success,
• failure rate,
• p50/p90/p99 latency,
• no-solution ratio.

Public documentation identifies a 45-second timeout state and notes that p90 below 15 seconds is generally considered fast enough for the Google Flights Best tab.

Treat those as partner behavior references, not as your own backend target.

Track:

provider_query_duration_ms
pricing_engine_duration_ms
supplier_fanout_duration_ms
serialization_duration_ms
total_response_duration_ms

11. Timeout and fallback

Do not design to the outer timeout.

Google timeout
   > your API timeout
      > supplier timeout

interface FlightPricingTimeouts {
  totalBudgetMs: number;
  supplierBudgetMs: number;
  fallbackBudgetMs: number;
}

Fallbacks can include cached prices, partial coverage or a controlled no-solution response.

12. Transport success is not business success

A 200 response is not enough.

Distinguish:

transport success
business success
priced solution found
bookable solution found

14. Retry policy

Do not retry every Live API failure. Unbounded retries increase latency and duplicate upstream load.

Potential retry candidates:

• transient network failures,
• selected provider 5xx responses,
• short-lived upstream timeouts,
• throttling/rate-limit signals with bounded backoff.

Do not blindly retry:

• malformed requests,
• unsupported itinerary/context,
• stale or invalid booking links,
• deterministic pricing-validation failures.

interface RetryPolicy {
  maxAttempts: number;
  baseDelayMs: number;
  maxDelayMs: number;
  retryableCodes: string[];
}

Retry time must fit inside the interactive latency budget. A controlled no-solution or fallback can be safer than approaching the outer Google timeout because of repeated retries.

13. Error taxonomy

GOOGLE_FLIGHTS_BAD_REQUEST
GOOGLE_FLIGHTS_TIMEOUT
GOOGLE_FLIGHTS_UNREACHABLE
GOOGLE_FLIGHTS_PARSE_ERROR
GOOGLE_FLIGHTS_NO_SOLUTION
GOOGLE_FLIGHTS_PRICE_MISMATCH
GOOGLE_FLIGHTS_LINK_INVALID
GOOGLE_FLIGHTS_STALE_PRICE

The public dashboard documents TIMEOUT, UNREACHABLE and ERROR states.

15. Correlation and idempotency

interface FlightPricingEnvelope {
  requestId: string;
  receivedAt: string;
  queryHash: string;
  request: FlightPricingRequest;
}

Passenger, market and currency dimensions must be part of any response-cache key.

16. Referral tracking

A referral is generated when a user selects a booking option in Google Flights.

interface GoogleFlightsReferralEvent {
  requestId: string;
  itineraryKey: string;
  providerId: string;
  displayedPrice: number;
  currency: string;
  clickedAt: string;
}

17. Conversion reconciliation

Google referral
    -> deeplink click
    -> booking created
    -> booking confirmed
    -> cancellation/refund
    -> matured booking

Track referral-to-booking, referral-to-matured-booking, cancellation and unattributed booking rates.

18. Travel Analytics Center and BigQuery

Google exposes partner quality/competitiveness data through Travel Analytics Center and BigQuery.

This enables:

• automated alerts,
• route-level anomaly detection,
• carrier-level quality scoring,
• price discrepancy trends,
• invalid-link monitoring.

Possible internal table:

google_flights_quality
- date
- integration_id
- origin
- destination
- trip_type
- marketing_carriers
- operating_carriers
- google_price
- partner_price
- price_diff_percentage
- is_valid_partner_link
- source

19. Monitoring

API

• query success,
• p50/p90/p99,
• timeout,
• unreachable,
• parse error,
• no-solution.

Price quality

• discrepancy rate,
• stale price,
• currency mismatch.

Link quality

• itinerary not found,
• invalid partner link,
• deeplink landing success.

Commercial

• referrals,
• conversion,
• matured conversion,
• revenue,
• cancellation-adjusted revenue.

20. Test matrix

21. Go-live checklist

• Google partner onboarding complete
• integration mode clear
• canonical flight model ready
• marketing/operating carrier separation
• request adapter tested
• response serializer tested
• price freshness policy defined
• timeout budget defined
• no-solution handling implemented
• booking-link validation implemented
• referral correlation implemented
• price discrepancy monitoring enabled
• itinerary-not-found monitoring enabled
• TAC ownership assigned
• BigQuery export/alerting evaluated

Summary

The correct abstraction is not “call the Google Flights API.”

It is:

Google Flights partner query/feed
        |
        v
Google adapter
        |
        v
Canonical flight pricing domain
        |
        v
pricing / availability
        |
        v
Google booking option
        |
        v
deeplink + referral
        |
        v
quality + conversion reconciliation

The implementation value comes from isolating the private partner contract from your flight domain and making price, itinerary and booking-link quality observable end to end.