What Is ARI? Availability, Rates & Inventory

ARI means Availability, Rates & Inventory.

It represents whether a hotel product is sellable, at what rate and with how much inventory for a given date/context.

Availability

Availability determines whether a room/rate can be sold for a stay date.

Restrictions can make an offer unavailable even when physical inventory exists.

Rates

Rates carry nightly pricing, currency and rate-plan context.

Taxes/fees, meal and cancellation semantics are also important to what the traveler sees.

Inventory

Inventory represents sellable capacity for a room type.

A rate may exist while the offer is not sellable because inventory reached zero.

Restrictions

ARI systems often represent rules such as minimum stay, maximum stay, closed-to-arrival, closed-to-departure and stop-sell. Incorrect restrictions can create rates that look valid but cannot be booked.

Push model

Google Hotels ARI differs from Pull-style flows because the partner pushes pricing/inventory state changes.

The partner therefore needs reliable change detection.

Change detection

The core question is:

Which property / room / rate / date state changed?

Incremental updates scale better than repeatedly sending all state, but a lost event can create stale data.

Snapshot and reconciliation

A robust architecture can combine continuous incremental updates with periodic state validation and replay/resynchronization when mismatches are discovered.

Taxes, fees and promotions

Google's ARI documentation also includes taxes, fees and promotions in the broader model.

ARI is therefore more than room count plus price.

Idempotency

Repeated delivery of the same update should not corrupt state.

Design deterministic keys and version/timestamp behavior.

Monitoring

Useful metrics include updates per minute, accepted/rejected messages, processing latency, last-update age, stale properties, retries, reconciliation mismatches and price accuracy.

When does ARI fit?

A push-based ARI model can fit well when you own inventory state, can emit reliable change events and operate at scale. If change tracking is weak, a query-driven model may be operationally safer.

Summary

A successful ARI system requires:

state ownership + change detection + reliable delivery + reconciliation + monitoring.

Production model: how should ARI state be stored?

The biggest modeling mistake is collapsing availability, rates and inventory into one "room open" flag. A durable model keeps room type, rate plan, date and restrictions separate.

property
  -> room_type
      -> rate_plan
          -> date
              - rooms_to_sell
              - open/closed
              - min_stay
              - max_stay
              - closed_to_arrival
              - closed_to_departure
              - occupancy pricing
              - price

This lets the system explain states such as "room exists but rate plan is closed," "rate is open but inventory is zero," or "the itinerary violates minimum stay."

How should synchronization work?

Prefer delta/event synchronization over unnecessary full refreshes when the provider supports it. Give each outbound update a stable identity:

property + room + rate + date-range + change-type + version

Replaying the same event should not corrupt state.

Common failure modes

• wrong room/rate mapping,
• timezone writing updates to the wrong date,
• inventory update arriving after a closure,
• out-of-order events,
• retry failure causing local/remote drift,
• full refresh overwriting newer state,
• restriction update being lost independently from price.

Request success is therefore not enough; state reconciliation is required.

KPIs to monitor

• accepted/rejected ARI update rate,
• update latency,
• provider error-code distribution,
• local-vs-remote drift count,
• stale availability age,
• inventory mismatch,
• restriction mismatch,
• retry count,
• post-booking inventory correction rate.

Production checklist

• Are room/rate mappings stable?
• Is date/timezone behavior explicit?
• Are delta updates idempotent?
• Are out-of-order events handled?
• Is remote state periodically reconciled?
• Are retryable and non-retryable errors separated?
• Does booking/cancellation feed inventory state back correctly?