Rate Parity & Geo-Pricing API
See the rate every market is quoted
Rate-parity and geo-pricing monitoring from a single API: one parameter prices the same room through a residential proxy in any market.
- A real captured spread: $1,771 from the US for the room Germany and Israel saw at $1,966, same dates, same currency
- One request per market: vary only
proxy_country, on any hotels endpoint - Honest by design: when parity holds, the API shows you that too (captured counter-example below)
Free tier on RapidAPI. No card to try.
POST /hotel_by_name · 3 requests, only proxy_country varied
captured run · 2026-08-26Rixos Sungate - The Land of Legends Access · Marine Room
| Priced from | proxy_country | Total for the stay |
|---|---|---|
| United States | "us" | $1,771 |
| Germany | "de" | US$1,966 |
| Israel | "il" | US$1,966 |
Spread: $195 between the cheapest and the most expensive market for the same room.
The mechanism, honestly
One field, one proxy exit per market
proxy_country takes a two-letter code and routes that single request through a residential proxy in that country, so the rates returned are the rates Booking.com quotes that market. Leave it out and the request uses the global residential pool. Each market is one request against your quota. A three-market check costs three requests.
The exact check behind the capture above
# one request per market. vary proxy_country
curl -X POST "https://booking-live-api.p.rapidapi.com/hotel_by_name" \
-H "Content-Type: application/json" \
-H "x-rapidapi-host: booking-live-api.p.rapidapi.com" \
-H "x-rapidapi-key: $RAPIDAPI_KEY" \
-d '{
"hotel_name": "Rixos Sungate",
"area": "Antalya",
"checkin_date": "2026-10-05",
"checkout_date": "2026-10-10",
"currency": "USD",
"proxy_country": "us"
}'The hero table is not an illustration: it is three real requests from 2026-08-26, identical except for proxy_country. The US market was quoted $1,771 for the Marine Room the German and Israeli markets were quoted US$1,966 for: a $195 spread on one room, one stay.
The check itself becomes the trivial part: no per-market scraping infrastructure to run. Your BI stack calls the API from wherever it already runs and compares numbers.
This is what makes rate-parity monitoring possible from a single API, which general-purpose hotel scrapers can't do: a request without market routing only ever shows you one market's rate.
The counter-example
When parity holds, you see that too
A monitoring tool that only ever finds discrepancies is a tool you cannot trust. Here is a capture from the same day where the three markets priced within a dollar of each other.
POST /hotel_by_name · same three markets
captured run · 2026-08-26Kremlin Palace · Superior Double or Twin Room
| Priced from | proxy_country | Total for the stay |
|---|---|---|
| United States | "us" | $1319 |
| Germany | "de" | US$1,318 |
| Israel | "il" | US$1,318 |
Spread: $1 between the cheapest and the most expensive market for the same room.
Kremlin Palace, Antalya: the same five-night stay, the same three markets, captured the same day as the Rixos run. The quotes came back within a dollar of each other.
For a revenue manager this is the point: most checks should confirm parity. The value of the monitor is that the day a market drifts (like the $195 Rixos spread), the number is in your data, not in a guest's screenshot.
Use cases
What teams build on this field
Each of these is the same three-line loop over markets, pointed at different properties.
Rate-parity enforcement
Price your own properties from the markets you sell in, on a schedule, and flag any market where the OTA quote drifts from your contracted rate, with the exact figure and a link to the live page.
OTA vs direct monitoring
Compare what Booking.com quotes each market against your direct-booking price for the same room and dates, so “book direct and save” stays a checkable claim per market rather than a hope.
Market-entry pricing research
Before pricing a new market, sweep your competitive set from that market's point of view: the quotes its residents actually see, not the ones your office IP sees.
Want to see it without writing code? The free hotel price by country tool runs this comparison in the browser.
Pricing
proxy_country is on every plan
| Plan | Price / mo | Requests | $ / 1k req | Overage | Rate limit | |
|---|---|---|---|---|---|---|
| BASIC | Free | 10 / mo | — | hard cap | 250 / min | Get this plan → |
| PRO | $10 | 2,000 / mo | $5.00 | $0.006 / req | 25 / min | Get this plan → |
| ULTRA | $20 | 6,500 / mo | $3.08 | $0.003 / req | 25 / min | Get this plan → |
| MEGA | $50 | 25,000 / mo | $2.00 | $0.002 / req | 50 / min | Get this plan → |
Every plan includes every endpoint. You only choose volume and rate limit. Read from the live listing on 2026-08-26; the listing is authoritative.
Questions, answered plainly
- Why do hotel rates differ by country at all?
- Booking.com shows different rates depending on where the visitor is browsing from. The API does not create that difference: it routes your request through a residential proxy in the market you name, so you can observe what each market is actually quoted.
- How does proxy_country work?
- It is a two-letter lowercase country code ("us", "de", "il") accepted by every hotels endpoint. The request exits through a residential proxy in that country. Leave the field out and the request goes through the global residential pool instead.
- Could the captured spread just be currency conversion?
- No. All three captured requests asked for USD explicitly, so the $195 difference on the Rixos Sungate room is market pricing, not exchange rates.
- What does a three-market check cost?
- Three requests against your plan quota, one per market. proxy_country is an ordinary request field on every plan, including the free tier.
- What if every market comes back the same?
- Then parity is holding, and that is also an answer: the Kremlin Palace capture on this page priced within a dollar across three markets. Monitoring means confirming parity most days and catching the exceptions the day they appear.
- Which endpoints accept proxy_country?
- All of them: /search, /hotel_by_name, /hotel and /resolve. A parity check usually runs on /hotel_by_name (headline rate) or /hotel (room-by-room).
Put a number on rate parity
One parameter, one request per market, and the spread is in your data instead of somebody’s anecdote.
Free tier: 10 requests/month. No card to try.