Use case
Rate parity, checked from inside each market
The same room, priced as a resident of Germany, Japan, or anywhere else would see it, from one API.
Booking.com shows different rates depending on where the visitor is browsing from, which means a hotel's published rate and the rate a given market actually sees can quietly diverge. Checking that by hand means VPNs, browser profiles, and screenshots, and it still doesn't scale past a handful of spot checks. A parity programme needs the market-specific view as structured data, on a schedule, for every property that matters.
How FlightPowers helps
The parity check as three parameters
proxy_country is the whole trick
A two-letter code routes the request through a residential proxy in that country. Same hotel, same dates, proxy_country varied: the response is what a local guest would be quoted, as JSON you can diff. Repeat each market a few times and the diff is one you can defend.
Query by name, not internal ID
/hotel_by_name resolves the hotel name a revenue manager would actually type. No ID-mapping table to build before the first check runs; an area field disambiguates the generic names.
One shape, even when sold out
Unavailable properties come back as available: false with nulls, the same shape as a priced result. Scheduled jobs keep running instead of crashing on the exceptional case.
Key workflows
A parity programme, end to end
- Define the watchlist. Properties by name, the markets that matter (say
deandjp), and the stay dates you track. - Sample each market, don't just poll it once. One
/hotel_by_namecall per country per sample: two markets asked three times each is six requests. One reading per market cannot tell a quoted difference from a rate that simply moved. - Normalise the currency. Set
currencyonce so every market answers in the same unit and the comparison is a subtraction. - Flag the gaps that hold. Alert when one market's whole sampled range clears your threshold against another's. Overlapping ranges are movement; a range that stays clear is the parity violation, timestamped.
- Go room-level when it matters.
/hotelreturns every room with its type, meal plan, and price, for the cases where the headline rate isn't the one that's off.
Questions, answered plainly
- How does per-country pricing actually work?
- Every hotels endpoint accepts proxy_country, a two-letter code like "de", "jp", or "us". The request is routed through a residential proxy in that country, so Booking.com responds exactly as it would to a local visitor. Ask for the same room from each market a few times and compare the ranges: that is the parity check.
- How many samples does a parity check need?
- More than one per market. In a controlled run on 2026-08-28, holding the property and dates fixed, 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. Sample each market about three times and treat a gap as real only when one market’s whole range sits below the other’s.
- Do I need Booking.com property IDs to monitor my hotels?
- No. /hotel_by_name takes the name a human would type and resolves it for you, with an optional area field to disambiguate generic names. If you prefer stable IDs, /resolve turns a name into the Booking.com path ID once, and you cache it.
- What happens when a property is sold out?
- Sold out or not found returns the same response shape with available: false and null prices, so your monitoring never has to branch on an error format. A sold-out night is a data point in a parity report, not an exception to handle.
See what each market is really being quoted
Live Booking.com rates through a residential proxy in the country you choose, by hotel name, on your schedule.
Free tier: 10 requests/month. No card to try.