---
title: "ARI vs Live Search vs Reprice: Hotel Pricing and Availability Lifecycle"
description: "Compare ARI, live search and reprice/check flows across freshness, granularity, latency, booking confidence and source-of-truth."
slug: "ari-vs-live-search-vs-reprice"
translationKey: "compare-ari-vs-live-search-vs-reprice"
locale: "en"
type: "comparison"
category: "hotel"
tags: ["ari","live-search","reprice","hotel-pricing","availability"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
sources:
  - title: "Google Hotels — ARI overview"
    url: "https://developers.google.com/hotels/hotel-prices/dev-guide/ari-overview"
  - title: "Expedia Rapid — Price Check"
    url: "https://developers.expediagroup.com/rapid/lodging/shopping/price-check"
  - title: "Hotelbeds — CheckRates"
    url: "https://developer.hotelbeds.com/documentation/hotels/booking-api/"
---
ARI, live search and reprice are not three versions of the same price lookup. They operate at different **time horizons and confidence levels**.

## Comparison matrix

| Dimension | ARI | Live Search | Reprice / Check |
|---|---|---|---|
| Scope | Room/rate/date state | Request-specific availability/offers | Selected offer/rate |
| Trigger | Source sync/change | User/search request | User selection / pre-book |
| Cardinality | Broad date/product matrix | Search context | One/few offers |
| Latency expectation | Async/background | Interactive | Interactive, booking critical |
| Freshness role | Sellability projection | Current searchable state | Transaction-near validation |
| Booking confidence | Medium | Higher | Highest |
| Typical output | availability/rate/restrictions | offers/rate keys | confirmed/changed/unavailable |

## What ARI solves

ARI means Availability, Rates & Inventory.

```text
property + room + rate plan + date
 -> inventory
 -> rate
 -> stop-sell
 -> min/max LOS
 -> CTA/CTD
```

ARI is effective for broad state projection before a user performs a full search.

An ARI snapshot is not a booking guarantee.

## What Live Search solves

Live Search sends request-specific context to the provider:

- check-in/out,
- occupancy,
- market/point of sale,
- currency,
- hotel/destination.

The response represents the available offer set at search time.

Multi-supplier systems must manage latency budgets and partial results.

## What Reprice solves

After a user selects an offer, the system revalidates a narrow piece of state before booking.

Examples include:

- Expedia Rapid → Price Check,
- Hotelbeds → CheckRates when RECHECK,
- flight/NDC → offer refresh/revalidate.

Map outcomes explicitly:

```text
MATCHED
PRICE_CHANGED
UNAVAILABLE
EXPIRED
POLICY_CHANGED
```

## Why all three can coexist

```text
ARI/cache
  -> broad discovery
  -> live search
  -> selected offer
  -> reprice/check
  -> booking
```

This pattern uses broad state for coverage/latency while improving booking confidence with final validation.

## Freshness model

One `updatedAt` field is not enough.

Keep separate timestamps such as:

- ariObservedAt,
- searchObservedAt,
- repriceObservedAt,
- bookingAttemptedAt.

An old ARI snapshot must not overwrite a newer reprice result.

## Failure modes

**ARI**
- stale inventory,
- lost restriction delta,
- date/rate-plan mapping drift.

**Live Search**
- timeout,
- partial suppliers,
- inconsistent tax semantics,
- quota pressure.

**Reprice**
- price changed,
- rate expired,
- sold out,
- policy changed,
- selected-offer identity lost.

## Product behavior

Do not label a search-result price as a confirmed booking price.

If reprice changes the amount, require explicit user reconfirmation.

A booking-create timeout is also a separate transaction state from successful reprice.

## Checklist

- [ ] Is ARI source/version timestamp retained?
- [ ] Is search observation separate?
- [ ] Is offer identity preserved through reprice?
- [ ] Is PRICE_CHANGED UX defined?
- [ ] Is reprice retry policy explicit?
- [ ] Is booking UNKNOWN modeled?
- [ ] Is price accuracy measured separately across search → landing → booking?