rate-parity-monitor

Rate Parity Monitor

Overview

proxy_country on the hotels REST API routes the request through a residential proxy in that country, so the same hotel and the same dates can be priced as a shopper resident there would see them. That turns a hotel lookup into a rate-parity and geo-pricing audit, which is a commercial job for revenue managers, distribution teams, and competitive-pricing analysts.

Two things make this harder than it looks, and the whole workflow below exists to handle them:

• Room rates move on their own. Two identical calls to the same market minutes apart can come back different. That movement can be as large as a genuine country-to-country gap, so a single call per country cannot tell the two apart.
• Real geo-pricing gaps are modest, and they depend on the property. In a controlled test on 2026-08-28, three independent Rome guest houses came back roughly 4% cheaper from Japan than from Germany, and that held across repeated samples. The same fixed test on a chain hotel returned an identical price from every country tried. Properties under a chain parity contract can show no gap at all, and that is a valid result, not a failed check.

So: fix one named property, sample every market more than once, and report a gap only when it is bigger than the movement you can see inside a single market.

Use travel-data-api for auth, base URL, and endpoint details. Parity work runs on the hotels REST host booking-live-api.p.rapidapi.com with the RapidAPI header pair, or on the ad-free hotels MCP server, where price_as_seen_from is the same input under a different name. The fields you compare across markets are available, price, price_string, room_type, and nights from POST /hotel_by_name.

Endpoints