Use case
Rate parity, checked from inside each market
The same room, priced as a visitor from the US, Germany, or Israel 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.
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
us,de,il), and the stay dates you track. - Loop the markets. One
/hotel_by_namecall per country per property: three markets is three requests. - Normalise the currency. Set
currencyonce so every market answers in the same unit and the comparison is a subtraction. - Flag the deltas. Alert when the spread between markets crosses your threshold: that spread 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 "us", "de", or "il". 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 three markets and compare what comes back: that is the parity check.
- 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.