ARI vs Live Search vs Reprice: Hotel Pricing and Availability Lifecycle

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

What ARI solves

ARI means Availability, Rates & Inventory.

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:

MATCHED
PRICE_CHANGED
UNAVAILABLE
EXPIRED
POLICY_CHANGED

Why all three can coexist

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?