Pull vs Changed Pricing vs ARI: Google Hotels Pricing Delivery

Pull, Changed Pricing and ARI use different operational models to pursue the same goal: keeping bookable Google Hotels rates fresh.

The right choice is not about which approach sounds newer; it depends on your change detection, latency and scale capabilities.

Comparison scope

This page does not select a winner. It compares which trade-offs appear under different use cases and operating constraints. Consumer UX, partner access, commercial contracts and technical integration are separate dimensions and should be evaluated independently.

Comparison

Pull

Google requests pricing for a hotel/itinerary and the partner responds.

The advantage is that the partner does not need perfect advance knowledge of every rate change.

The challenges are query volume, latency, upstream dependencies and timeout management.

Changed Pricing

Changed Pricing adds a mechanism to help identify which combinations need refreshing.

When a partner can reliably detect changes, this can reduce unnecessary requests.

If change detection is wrong, stale-price risk increases.

ARI

ARI pushes changes in availability, rates and inventory.

It can fit connectivity systems that already own a strong state/change pipeline.

Success requires reliable inventory state, incremental tracking, restrictions, taxes/fees consistency and delivery/retry behavior.

Decision patterns

Pull fits systems with on-demand pricing and limited change events.

Changed Pricing fits systems that know where changes occurred but do not want a fully push-based ARI model.

ARI fits systems with strong rate/inventory state, incremental events and high-volume push requirements.

Think beyond one protocol

Cache, live-query fallback and monitoring should be designed around the delivery model.

Measure before deciding

During a pilot, monitor requests per property, p95 pricing latency, stale-rate frequency, update volume, infrastructure cost, price accuracy and recovery time.

Real measurements are more useful than architectural preference alone.

Summary

All three models target freshness; they distribute operational ownership differently.

The central question is how reliably your system knows when pricing state changes.

Selection criterion: where is the source of truth?

The most useful question is not “which protocol is faster?” but where authoritative rate/inventory state lives and which system can reliably detect changes. That answer also shapes caching, retries, replay and observability.