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.
- Check the same room as a resident of another country: vary only
proxy_country, on any hotels endpoint - A repeat-sampled run, not one reading: 3 identical requests per market, so the movement inside a market is visible next to the difference between markets
- Honest by design: when the markets agree, the API shows you that too (captured counter-example below)
Free tier on RapidAPI. No card to try.
3 properties × 3 markets × 3 identical requests
captured run · 2026-08-28| Property | Germany "de" | Japan "jp" | United States "us" |
|---|---|---|---|
| Favola Romana - Guest House | 243 | 234 | 242–258 |
| Suite della Pigna | 486 | 467 | 482–523 |
| Suites 51 | 477 | 460 | 473–512 |
3 identical requests per market. One number means every request came back the same; a range means the market moved on its own, by up to 9% here.
Short answer
What proxy_country does to a hotel response
api.flightpowers.com and on booking-live-api.p.rapidapi.com takes proxy_country, a two-letter code that routes that single request through a residential proxy in that market. The response shape does not change; the rate does, when the property prices differently for that market. Vary only that field, hold the property, dates and currency fixed, and you have rate-parity and geo-pricing monitoring from one API.{
"us": {
"room_type": "Marine Room",
"price_string": "$1,771",
"price": 1771,
"nights": 5
},
"de": {
"room_type": "Marine Room",
"price_string": "US$1,966",
"price": 1966,
"nights": 5
},
"il": {
"room_type": "Marine Room",
"price_string": "US$1,966",
"price": 1966,
"nights": 5
}
}| Field | Type | Meaning | Captured run |
|---|---|---|---|
proxy_country | string (request) | Two-letter country code. Accepted by /search, /hotel_by_name, /hotel and /resolve. Leave it out and the request uses the global residential pool. | us · de · il |
price / price_string | number · string | The same room, as each market was quoted it, total for the stay. This is the only field a parity check is really watching. | 1771 · 1966 · 1966 |
room_type | string | null | Must be identical across the markets you compare. If it moves, the markets were quoted different products and the price gap means nothing. | Marine Room |
currency | string (request) | Hold it fixed across the markets or you are measuring exchange rates instead of pricing. | USD |
nights | number | null | The stay each quote covers, echoed back. Same dates in, same nights out, on every market. | 5 |
available | boolean | A market that cannot book the room at all returns false rather than a price. Check it before comparing anything. | true |
One request per country is not a measurement. In the repeat-sampled run above, 3 identical requests went to each of 3 markets for each of 3 properties, and the US market moved between identical requests by more than the gap between the other two. Sample each market several times against a fixed property, and treat a gap as real only when one market's whole range sits below the other's.
Parity holding is a result too. The Kremlin Palace capture priced within a dollar across the same three markets on the same dates. Most days a monitor confirms nothing moved; its value is the day something does.
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. Every request counts against your quota, and a check worth trusting repeats each market a few times: two markets sampled three times each is six requests.
The exact check behind the run above
# one request. a real check repeats it: 3 times per market,
# because a market's own quote moves between identical requests.
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": "de"
}'The hero table is not an illustration: it is 27 real requests from 2026-08-28, one property at a time, identical except for proxy_country. Japan came in under Germany on all three properties, and both markets answered with the same number every time they were asked. The US market did not: it moved between identical requests, by more than the Germany–Japan gap.
That is the whole method. Hold the property and the dates fixed, ask each market more than once, and treat a gap as real when one market's whole range sits below the other's. Rates move, so sample each country a few times before you call a gap real.
The infrastructure is the trivial part: no per-market scraping to run. Your BI stack calls the API from wherever it already runs and compares ranges. That 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.
Two earlier readings
What one request per market can and cannot tell you
Both captures below are real, taken on 2026-08-26, and both are a single request per market. That makes them readings rather than measured gaps: useful as the start of a check, not as its conclusion.
POST /hotel_by_name · one request per market
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 |
Difference in this sample: $1 between the cheapest and the most expensive market. Rates move between identical requests, so sample each market a few times before you call a gap real.
Rixos Sungate, Antalya · one request per market
Rixos 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 |
Difference in this sample: $195 between the cheapest and the most expensive market. Rates move between identical requests, so sample each market a few times before you call a gap real.
Kremlin Palace, Antalya: a five-night stay quoted within a dollar of itself from all three markets. Nothing to chase, and that is a real answer. Chain properties under parity contracts often look exactly like this.
Rixos Sungate, same day and same markets, came back further apart. But that is one reading from each market, and the repeat runs above show a market moving on its own by a comparable amount. So the honest call is “re-sample this one”, not “parity is broken”.
For a revenue manager that distinction is the job. Most checks should come back quiet. The value of the monitor is the morning one doesn't, with enough samples behind it that you can act on the number instead of arguing about it.
Use cases
What teams build on this field
Each of these is the same loop: hold the property fixed, sample each market a few times, compare the ranges.
Rate-parity enforcement
Price your own properties from the markets you sell in, on a schedule, and flag a market only when its whole sampled range drifts from your contracted rate, with the figures 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 | — | 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 → |
Swipe the table sideways for overage and rate limits.
Every plan on this API includes all of its endpoints; flights and hotels are separate subscriptions. Read from the live listing on 2026-09-11; 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.
- How many times should I ask each market?
- More than once. In a controlled run on 2026-08-28 the German and Japanese markets returned the same number on every request, while the US market moved between identical requests by more than the Germany–Japan gap. Three samples per market is enough to tell a steady quote from a moving one; a single reading per market cannot.
- When is a difference between markets real?
- When one market’s whole sampled range sits below the other’s. Overlapping ranges mean the rate is moving, not that a market is being quoted differently. Set currency explicitly on every request so the comparison is a subtraction and not an exchange-rate question.
- What does a check cost?
- One request per market per sample: two markets sampled three times each is six requests against your plan quota. proxy_country is an ordinary request field on every plan, including the free tier.
- What if every market comes back the same?
- Then nothing is drifting, and that is also an answer: the Kremlin Palace capture on this page priced within a dollar across three markets, and a separate held-constant run on a chain hotel on 2026-08-28 returned the identical price from every market we tried. Chain properties under parity contracts often show no gap at all. Monitoring means confirming that 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, a few samples per market, and the answer is in your data instead of somebody’s anecdote.
Free tier: 10 requests/month. No card to try.