Do hotel prices change by country?

Published September 5, 2026 · Updated October 6, 2026

Short answer: Sometimes, and it depends on the hotel, the room and the day. FlightPowers' Booking.com endpoints take a proxy_country field (a two-letter code) that sends the request through a residential proxy in that market, so you can price a stay as a resident of that country would see it. A 2026-08-28 run found Japan about 4% under Germany on three Rome properties across repeat samples. A 2026-10-06 run on one of those properties found no gap between Germany and Japan at all, and gaps of 3% to 16% between Germany and the US once the comparison was made room by room.

Booking.com can quote a different rate depending on where the visitor appears to be browsing from. Every hotels endpoint here takes proxy_country, a lowercase two-letter code; leave it out and the request goes through the global pool. The mechanism is simple. Measuring what it does is not, and this page is mostly about the measuring.

How do you make the request?

Same call as any other lookup, one extra field. This is the exact request behind the 2026-10-06 tables below, with de swapped for jp and us:

curl -X POST "https://api.flightpowers.com/v1/hotels/by-name" \
  -H "Content-Type: application/json" \
  -H "x-api-key: $RAPIDAPI_KEY" \
  -d '{
    "hotel_name": "Suite della Pigna",
    "area": "Rome",
    "checkin_date": "2026-11-18",
    "checkout_date": "2026-11-21",
    "adults": 2,
    "currency": "EUR",
    "proxy_country": "de"
  }'

proxy_country is on the free plan too. Keys come from the RapidAPI listing.

What did the first controlled run show?

Three Rome properties, three markets, three identical requests per market through the search endpoint. Only proxy_country changed. Captured 2026-08-28, totals for the stay in the same currency.

Read the rows before the columns. Japan came back about 4% under Germany on all three properties, and it held across three repeat runs. That is a real gap, and it is modest.

Then look at us. Three identical requests, seconds apart, returned 486, 523 and 482 on one property. That spread inside one market is larger than the gap between markets. Sample us once against a single de call and you would have "found" a 7.6% difference that is mostly noise.

What did the same check show five weeks later?

On 2026-10-06 I ran it again on one of those properties, Suite della Pigna, for a three-night stay on 18 to 21 November 2026, two adults, in euros. This time through the by-name endpoint, three samples per market, interleaved de, jp, us so no market got a quiet minute to itself.

Two findings, and the second matters more.

Germany and Japan were identical this time, on the same property where Japan ran about 4% under Germany in August. A gap you measured once is a fact about the day you measured it, not about the hotel.

The us rows look like a 15% gap and are not one. The headline rate is the cheapest room Booking.com shows that market, and from us that was a Deluxe Room, not the Premium room the other two markets got. €573 against €497 compares two different rooms. The room_type field is in every answer for exactly this reason: check it before you subtract.

How do you compare room to room?

With the rooms endpoint, which lists every room and rate plan for one property. I resolved the name to its Booking.com ID once and then asked for the room list from de and from us, twice each, a few seconds apart:

curl -X POST "https://api.flightpowers.com/v1/hotels/rooms" \
  -H "Content-Type: application/json" \
  -H "x-api-key: $RAPIDAPI_KEY" \
  -d '{"hotel_booking_id": "it/amazing-rooms-piazza-venezia", "checkin_date": "2026-11-18",
       "checkout_date": "2026-11-21", "adults": 2, "currency": "EUR", "proxy_country": "us"}'

The non-refundable rate for each room type, total for three nights:

de listed two non-refundable Deluxe rates (€511 and €591) and us one (€494), so that row compares the cheapest of each. The free-cancellation rates were lower from us as well, by about 9% on each of the three rooms that had one.

So on this hotel, on this day, the market gap was not one number. It was zero on one room, 3% on another and 16% on two more, and it pointed the other way from the headline-rate table. And us was again the least stable market: its first room list had no Premium room at all, its second did.

One more thing you will notice: the room list priced the Premium room at €452 from de, while the by-name call priced it at €497 from the same market. The two endpoints read two different Booking.com pages, and with proxy_country set they did not print the same total for that room (with no proxy_country, both said €497). So keep every comparison inside one endpoint. A gap between a by-name number and a room-list number is not a market gap.

How to measure it honestly

Repeat every market. One call per country is not a measurement, it is one draw from a distribution you have not looked at. Sample each market several times and record the spread next to the median.

Hold the property fixed, then the room. Compare one named property with itself across markets, and then one room type and rate plan with itself. Comparing "the first result" between markets compares different hotels, because result order changes between identical runs. Comparing headline rates can compare different rooms, as the us row above did.

Do not anchor on us. It was the least stable market in both runs. Pick a market that repeats cleanly, like de here, as your baseline.

Date every claim. "Japan ran about 4% under Germany on these three properties, on 2026-08-28, over three samples" is a claim you can defend. "Prices vary by up to 16% across countries" is not, even though one row above shows 16%.

price_as_seen_from is an input parameter on the keyed hotels MCP server, the same idea as proxy_country. It is not a field in the REST response, so do not go looking for it in the JSON.

What does a check like this cost?

Every call is one request. The 2026-10-06 run above was nine by-name lookups with proxy_country (three markets, three samples), one without it, one resolve and five room lists: 16 requests. A three-market, three-sample check on one property fits inside the free plan's 10 a month, once. A daily check on a comp set does not: ten properties, two markets, three samples is 60 requests a day, about 1,800 a month, which is what PRO's 2,000 for $10 is sized for. Current plans always live on /pricing.

Related

• Hotel rates API: every room price for one hotel by name: the two endpoints used above, with full responses
• Geo-Pricing API: the product page, with the captured runs
• How to monitor hotel rate parity: the scheduled version, for brand and channel monitoring
• Hotel Price by Country: the market check in the browser, on our key