Google Hotel Feeds: Data Contracts and Recovery

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 explains the platform and operational ownership. This page describes feed responsibilities and recovery decisions. Use the integration guide 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 ↗, pricing delivery, room/package information and landing pages ↗. Use separate validation and ownership for each. The table describes responsibilities, not a universal delivery order or a complete XML schema.

Google's ARI reference 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 ↗ and POI specification ↗. 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.

{
  "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.

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

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, this feed reference and the implementation guide together during incident review: they answer respectively who owns the problem, which contract is involved and how that contract is implemented.