---
title: "Google Hotel Feeds: Data Contracts and Recovery"
description: "Separate Google Hotel List, pricing, ARI, POI and landing contracts; diagnose stale updates and design publication, recovery and monitoring workflows."
slug: "google-hotel-feeds"
translationKey: "platform-google-hotel-feeds"
locale: "en"
type: "profile"
category: "feed-platform"
tags: ["google-hotels","feed","hotel-list","poi","pricing","landing-page"]
vertical: ["hotel"]
platform: "Google Hotel Feeds"
domain: "google.com"
publishedAt: "2026-09-19"
updatedAt: "2026-09-21"
reviewedAt: "2026-09-21"
directory: {"status":"active","platformType":"feed","audiences":["b2b"],"businessModels":[],"integrationMethods":["feed","push","pull"],"docsUrl":"https://developers.google.com/hotels/hotel-prices/dev-guide/data-feeds","guideTranslationKey":"integration-google-hotels","sources":[{"title":"Google Hotel Prices — Integration overview","url":"https://developers.google.com/hotels/hotel-prices/dev-guide/data-feeds"}],"reviewedAt":"2026-09-21"}
sources:
  - title: "Google Hotels — Integration overview"
    url: "https://developers.google.com/hotels/hotel-prices/dev-guide/data-feeds"
  - title: "Google Hotels — Hotel List"
    url: "https://developers.google.com/hotels/hotel-prices/xml-reference/hotel-list-feed"
  - title: "Google Hotels — Pricing delivery modes"
    url: "https://developers.google.com/hotels/hotel-prices/dev-guide/delivery-mode"
  - title: "Google Hotels — ARI overview"
    url: "https://developers.google.com/hotels/hotel-prices/dev-guide/ari-overview"
  - title: "Google Hotels — Landing pages"
    url: "https://developers.google.com/hotels/hotel-prices/dev-guide/pos-overview"
  - title: "Google Travel Partner API"
    url: "https://developers.google.com/hotels/hotel-prices/api-reference/rest"
  - title: "Google Lodging — POI feed"
    url: "https://developers.google.com/actions-center/verticals/lodging/reference/point-of-interest-feed"
  - title: "Google Lodging — Aggregator integration"
    url: "https://developers.google.com/actions-center/verticals/lodging/overview"
---

Google hotel connectivity uses several data contracts with different identities, update patterns and failure consequences. Treating them as one “hotel feed” hides dependencies: a valid property export does not prove that room inventory, stay pricing or the booking destination is correct.

The [Google Hotels profile](/en/metasearch/hotels/google-hotels) explains the platform and operational ownership. This page describes feed responsibilities and recovery decisions. Use the [integration guide](/en/integrations/google-hotels-integration) for authentication, request/response examples and adapter implementation.

## Production scenario: rate update accepted, offer still wrong

A fictional channel manager changes a room rate and closes arrivals on a busy date. Its exporter reports success, but a sampled landing still offers the old stay. Investigating only the rate file misses two separate questions: did the restriction change reach the relevant contract, and was the sampled offer based on the same room/rate and revision?

Build an incident timeline from source mutation, normalization, serialization, delivery and observed result. A transport acknowledgement answers only one step in that timeline. Keep property matching, price processing and booking-engine behavior as separate observations.

## Which data belongs to which contract?

Google's documentation separates the [Hotel List](https://developers.google.com/hotels/hotel-prices/xml-reference/hotel-list-feed), pricing delivery, room/package information and [landing pages](https://developers.google.com/hotels/hotel-prices/dev-guide/pos-overview). Use separate validation and ownership for each. The table describes responsibilities, not a universal delivery order or a complete XML schema.

| Contract | Main responsibility | What it does not establish |
|---|---|---|
| Hotel List | Property identity; XML listings | A current sellable stay |
| Pull / Changed Pricing response | Itinerary pricing through Transaction messages | Complete property matching |
| ARI message family | Room/rate model, rates, inventory and restrictions | A valid booking journey by itself |
| Landing-page file | Partner URL destinations and matching rules | The checkout total |
| Travel Partner API | Supported Hotel Center management/reporting | A replacement for all pricing contracts |

Google's [ARI reference overview](https://developers.google.com/hotels/hotel-prices/dev-guide/ari-overview) identifies Transaction property data, rate, inventory and availability messages as necessary before ARI pricing is available. Optional message families support further pricing behavior. Do not treat one successfully submitted rate message as a complete initialization.

## Hotel List and Actions Center POI are separate integrations

Hotel List belongs to Hotel Prices. Actions Center Lodging publishes its own [aggregator integration](https://developers.google.com/actions-center/verticals/lodging/overview) and [POI specification](https://developers.google.com/actions-center/verticals/lodging/reference/point-of-interest-feed). They can both describe a property, but one is not a drop-in replacement for the other. Choose the contract associated with the approved integration.

For example, the POI specification defines a partner-generated `poi_id` and distinguishes required property information from optional fields. Its property website URL is used for matching. Do not assume it is the booking destination configured in a Hotel Prices landing-page file.

Maintain a shared internal property record if useful, then generate independent adapters. Keep schema validation, identifiers, onboarding and diagnostics separate. This avoids “valid JSON, wrong product” failures when an exporter is repurposed for another Google surface.

## Internal publication model

The following JSON is an illustrative internal audit record. It is neither a Google API request nor a schema accepted for upload.

```json
{
  "publicationId": "pub-1042",
  "contract": "hotel-prices-ari-availability",
  "partnerPropertyId": "H-104",
  "roomTypeId": "DBL",
  "ratePlanId": "FLEX",
  "sourceRevision": 42,
  "observedAt": "2026-09-21T10:00:00Z",
  "affectedStayDates": ["2026-10-10"],
  "payloadDigest": "sha256:example",
  "state": "awaiting-observation"
}
```

The revision identifies the source state; the digest identifies serialized bytes. The contract name distinguishes an availability update from a rate or property update. Add the actual request identifier and response details to your audit trail where the transport provides them. Do not label an acknowledged update “visible” without a corresponding observation.

In a multi-tenant exporter, include account ownership in the publication key. A property ID alone may be unique only inside a partner account. Use stable identity mappings instead of deriving IDs from names or array positions.

## Publishing flow and recovery boundaries

A recommended internal flow is: capture a source snapshot, normalize it, validate the target contract, serialize, publish, classify the response, then reconcile observable state. These are your pipeline stages, not promises of transactional processing across Google's services.

| Boundary | Validation before proceeding |
|---|---|
| Source to canonical model | Stable IDs, guest semantics, currency and stay dates |
| Canonical model to contract | Supported fields and required dependencies |
| Serialized payload to transport | Syntax, encoding, target account and payload size |
| Response to internal status | Transport status plus any contract-level errors |
| Delivery to observation | Matching/processing evidence and equivalent offer checks |

A current-state reconciliation job should detect gaps left by lost events. Its cadence is an internal operating choice. Replay should be contract-aware: do not blindly restore an old pricing payload because an earlier release was technically successful. It may reopen inventory that has since closed.

## Failure modes: distinguish stale, empty and rejected data

Missing data is not a universal delete instruction. Before removing an entity or clearing availability, follow the deletion or update semantics of the specific contract. Your adapter should never invent one rule for property lists, Transaction messages and ARI updates.

For out-of-order events, compare source revisions within the correct entity and contract scope before serialization. This is internal stale-update protection, not an assumed Google idempotency guarantee. Keep duplicate transport attempts distinct from duplicate business changes.

For failures, first classify authentication, malformed payload, unsupported values, temporary transport failure and ambiguous outcome. Repair deterministic validation errors before retrying. Bound retries for transient failures and record what was attempted; after a long delay, re-evaluate whether the source snapshot is still current.

## Landing pages are an independent release surface

A feed release can leave rates correct and clicks broken. Version landing configuration separately, and test the generated URL in a clean session with the intended dates and guests. Check that default currency, occupancy and room selection do not silently change the comparison.

Google's landing-page documentation limits each file to one partner. Treat account/partner ownership as part of deployment validation. For the implementation details and supported substitution variables, follow the [landing-page section of the integration guide](/en/integrations/google-hotels-integration#12-landing-page-integration) and the current official reference.

## Monitoring and test matrix

Measure processing stages independently. Useful internal signals include rejected entities by reason, source-to-publication lag, unmatched properties, stale revisions suppressed, unresolved delivery outcomes and landing mismatches. Do not report a global “feed success rate” without defining which stage and denominator it measures.

| Test | Evidence to retain |
|---|---|
| Property rename with stable identity | Canonical-to-partner mapping before and after |
| New room/rate dependency | Model version and dependent update outcomes |
| Arrival restriction changes | Source state, delivery and equivalent-stay observation |
| Old event arrives after a new event | Revision comparison and suppressed payload |
| Retry follows an ambiguous response | Attempt history and reconciliation result |
| Wrong-account export | Pre-publication ownership validation failure |
| Landing configuration changes | Generated destination and clean-session result |

Before production expansion, assign recovery ownership for each failure class and prove that the exporter can reconcile a missed update. Confirm that source snapshots and observations can be joined without exposing credentials or guest data. The schemas and supported behavior come from the linked official references; the audit model, recovery strategy and test matrix are engineering recommendations.

Keep the [platform profile](/en/metasearch/hotels/google-hotels), this feed reference and the [implementation guide](/en/integrations/google-hotels-integration) together during incident review: they answer respectively who owns the problem, which contract is involved and how that contract is implemented.