---
title: "What Is ARI? Availability, Rates & Inventory"
description: "Learn how ARI models availability, rates, inventory, restrictions, taxes/fees and push-based hotel distribution updates."
slug: "what-is-ari"
translationKey: "learn-what-is-ari"
locale: "en"
type: "guide"
category: "integration"
tags: ["ari","availability","rates","inventory","hotel","google-hotels"]
featured: true
publishedAt: "2026-09-19"
updatedAt: "2026-09-19"
reviewedAt: "2026-09-19"
sources:
  - title: "Google Hotels — ARI overview"
    url: "https://developers.google.com/hotels/hotel-prices/dev-guide/ari-overview"
---
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.

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

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