---
title: "Google Flights Partner Integration: Live API & Price Feed Developer Guide"
description: "Design a Google Flights partner integration around Live API, Price Feed, Price Through Google, booking links, request-response boundaries, latency, price quality and Travel Analytics Center."
slug: "google-flights-integration"
translationKey: "integration-google-flights"
locale: "en"
type: "guide"
category: "integration"
tags: ["google-flights","flight","live-api","price-feed","booking-link","price-accuracy","travel-analytics"]
vertical: ["flight"]
platform: "Google Flights"
domain: "support.google.com"
featured: true
publishedAt: "2026-09-20"
updatedAt: "2026-09-21"
reviewedAt: "2026-09-20"
sources:
  - title: "Google Flights — Live API Performance"
    url: "https://support.google.com/travelanalytics/answer/15669585"
  - title: "Google Flights — Quality"
    url: "https://support.google.com/travelanalytics/answer/11230452"
  - title: "Google Flights — Referrals"
    url: "https://support.google.com/travelanalytics/answer/11505733"
  - title: "Google Flights — Data in BigQuery"
    url: "https://support.google.com/travelanalytics/answer/14839637"
  - title: "Google Travel Help — Flight and booking options"
    url: "https://support.google.com/travel/answer/11583641"
---

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](/en/metasearch/flights/google-flights). 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:

```text
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.

```text
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.

```ts
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;
}
```

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

## 4. Internal response model

```ts
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.

```ts
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.

```ts
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:

```text
feed accepted != price still valid
```

## 7. Price Through Google

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

Architecture questions:

```text
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.

```ts
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:

```text
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:

```text
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.

```text
Google timeout
   > your API timeout
      > supplier timeout
```

```ts
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:

```text
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.

```ts
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

```text
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

```ts
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.

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

## 17. Conversion reconciliation

```text
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:

```text
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

| Test | Expected |
|---|---|
| one-way | correct itinerary |
| round-trip | correct two-slice solution |
| multiple passengers | context preserved |
| business cabin | correct cabin |
| interline | carrier chain preserved |
| codeshare | marketing/operating distinction |
| no inventory | no-solution |
| stale price | mismatch alert |
| invalid deeplink | link-quality alert |
| overload | controlled timeout |
| supplier timeout | fallback/no-solution |
| expired feed price | not treated as fresh |

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

```text
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.