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 the US, Germany, or eleven other countries.
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 |
Spread: $195 between the cheapest and the most expensive market for the same room.
How it works
One parameter does all the travelling
1
Name the hotel, pick the markets
The name a human would type, no property IDs. Add an area to disambiguate, choose 2–3 countries.
2
We ask from each country
One real Booking.com lookup per market, identical except proxy_country, each routed through a residential proxy in that country at request time.
3
Compare the quotes
Same room, same dates, side by side, with the spread computed. When the markets agree, the tool says parity is holding rather than inventing a difference.
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 catch the $195-style spreads before your account manager does.
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 are a clean methodology section waiting to happen.
The honest counter-example
Parity can hold too
A monitoring tool that only ever finds differences is selling you something. Same capture date, same three markets, different property:
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 |
Spread: $1 between the cheapest and the most expensive market for the same room.
Three markets, all within a dollar. The Rixos Sungate capture above (same dates, same markets) showed a $195 spread on the same room. Which of the two your property looks like is exactly what monitoring answers.
Scale it
Watching a whole comp set? That's what the API is for
This page checks one hotel at a time, from at most three 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 13-country list is 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 the spread
Flat JSON per market makes the diff trivial: compare price across runs, alert when the gap crosses your threshold.
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 each selected market is a real request routed through a residential proxy in that country, 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 captured runs 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 and the price differences are the finding.
- What if all markets come back with the same price?
- Then parity is holding for that property and dates. That is a real answer, not a failed check. The captured Kremlin Palace example on this page shows exactly that, within a dollar across three markets. A monitoring setup wants both outcomes: the spread and the all-clear.
- Why only 2–3 markets, and only from a fixed list?
- Demo economics: each market is one proxied call on our key, so the demo allows 13 allowlisted countries and at most 3 per run. From your own code there is no such list: one request per market you care about, as many as your plan’s rate limit lets you fire.
- What does “sold out” or “search failed” in a row mean?
- Sold out means Booking.com answered from that market with no availability for your dates. Search failed means that one proxied request didn’t complete. The other markets still stand, 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, alerting on spread. 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.