Free tool · live demo, rate-limited
Hotel Price by Country
Booking.com doesn't quote one price; it quotes one per market. Pick a hotel and dates and see what the same room costs a visitor from two countries. Each market is asked three times, because a rate can move between identical requests and one reading each would not tell you which was which.
Three Rome properties, three markets, three requests each
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.
Japan came in under Germany on all three properties, and both markets returned the same number on every request. The US moved on its own between identical requests, by more than the Germany–Japan gap. Run your own check above.
How it works
One parameter does all the travelling
1
Name the hotel, pick two markets
The name a human would type, no property IDs. Add an area to disambiguate, then pick the two countries to compare.
2
We ask each country three times
Six real Booking.com lookups, identical except proxy_country, each routed through a residential proxy in that country at request time.
3
Compare the ranges, not two readings
You see every request and the range each market landed in. A gap counts when one market’s whole range sits below the other’s; overlapping ranges are movement, not a finding.
Who it's for
A tool for people whose job is the rate
Travellers save a few dollars with a VPN. Businesses monitor this; that's who the API sells to.
Revenue managers
Rate parity is a contract term, and breaches hide in markets you don't browse from. Check your own property from the markets that matter, on a schedule, and see a drift the day it appears rather than in a guest's screenshot.
OTAs and metasearch
Geo-pricing intelligence at the source: what your competitor's channel actually quotes each market, not what their rate feed claims. Per-country data is the difference between a hunch and a report.
Analysts and consultants
Pricing studies need observed prices, not brochure rates. Identical requests that differ only in proxy_country, repeated enough times to show the movement, are a clean methodology section waiting to happen.
Two earlier readings
What one request per market can and cannot tell you
Both of these are real, captured on 2026-08-26, and both are a single request per market. Read them as readings, not as measured gaps.
Rixos Sungate, Antalya · 2026-10-05 → 2026-10-10
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 |
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.
One request per market, so this is where the check starts, not where it ends. The repeat runs above show a market moving on its own by roughly this much, so the honest reading is “worth re-sampling”, not “parity is broken”.
Kremlin Palace, Antalya · 2026-10-05 → 2026-10-10
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.
Same day, same markets, different property: three quotes within a dollar. Nothing to chase. A tool that only ever finds differences is selling you something.
Scale it
Watching a whole comp set? That's what the API is for
This page checks one hotel at a time, from two markets. Your code doesn't have those limits.
Any market, not an allowlist
proxy_country takes a two-letter code on every hotels endpoint; the demo's short list and its two-market pair are a demo budget, not an API limit.
By name, on a schedule
The by-name endpoint resolves the property for you, so a comp-set sweep is a list of names and a cron, no ID bookkeeping.
Alert on a gap that holds
Flat JSON per market makes the diff trivial: sample each market, compare the ranges, alert when one market's whole range clears your threshold against another's.
Questions, answered plainly
- Why would the same room cost different amounts by country?
- Booking.com shows different rates depending on where the visitor is browsing from: market-specific promotions, currency handling, and channel deals all move the number. The only way to see it is to genuinely ask from each market, which is what the per-country residential proxy does.
- Is this tool really free?
- Yes: no account, no email. But a run is six real requests, each routed through a residential proxy, the most expensive kind of call we serve, so this tool carries the tightest per-visitor cap on the site and repeated queries come from a short cache. The page shows a captured run until you run one.
- What is proxy_country exactly?
- A request parameter on the hotels API. Set proxy_country to a two-letter code and the request routes through a residential proxy in that country, so Booking.com answers as if a local were asking. Vary only that parameter across otherwise-identical requests, repeat each one a few times, and the difference between the ranges is what you can act on.
- Why does the tool ask each market three times?
- Because a market can answer differently to the same question. In a controlled run on 2026-08-28 the German and Japanese markets returned an identical number on every request, while the US market moved between identical requests by more than the Germany–Japan gap. One reading per market cannot tell those two situations apart; three readings can.
- What if both markets come back with the same price?
- Then nothing is drifting for that property and those dates, which is a real answer rather than a failed check. Chain properties under parity contracts often look exactly like this. A monitoring setup wants both outcomes: the gap and the all-clear.
- Why only two markets, and only from a short list?
- Demo economics, spent on the right thing: six proxied calls buys two markets sampled three times each, which is a comparison, instead of six markets sampled once, which is six readings. From your own code there is no list and no pair limit: any two-letter code, as many markets and repeats as your plan’s rate limit allows.
- What does “no rate came back” in a row mean?
- Either Booking.com answered from that market with no availability for your dates, or none of that market’s requests completed. The other market still stands, and the tool reports the row honestly instead of dropping it.
- Can I automate this across a whole comp set?
- That is the intended production shape: the same by-name lookup across your properties and markets on a schedule, sampled a few times each, alerting when one market’s whole range clears another’s. The card under the results shows the exact code, pre-filled with the hotel and markets you just checked.
Rate-parity monitoring is one parameter away
Live Booking.com rates with proxy_country on every endpoint: the same check you just ran, as a scheduled job. Free tier on RapidAPI, no card to try.
Free tier: 10 requests/month. No card to try.