Do I need to map my comp set to internal property IDs first?

No. /hotel_by_name takes the hotel name a human would type (with an optional area field like “Antalya” to disambiguate) and resolves it for you. If you want stable references for a long-running tracker, call /resolve once per property to get its Booking.com ID, cache it, and hit /hotel directly on every check after that.

What does each check return?

The headline rate for your dates as both a string and a number, plus review_score, review_count, and room_type, and a booking link. Sold out or not found returns the same shape with available: false and nulls, so a scheduled tracker never branches on error formats.

How many requests does daily comp-set tracking cost?

One request per property per stay-date you track. A 5-property set checked daily for one target date is ~150 requests a month, inside the hotels Pro plan ($10/month, 2,000 requests). Tracking several stay dates or adding per-market checks with proxy_country scales the count linearly, which is what the larger tiers are for.

← All use cases

Use case

Your comp set, checked every morning

Live rates for the properties you price against, queried by name, returned as data.

Every revenue manager has a competitive set, and most still check it by opening Booking.com in five tabs. The manual check doesn't keep history, doesn't run on weekends, and doesn't scale past a handful of properties or dates. Automating it usually stalls on plumbing: hotel APIs want internal property IDs before they answer anything, and a sold-out competitor (the most interesting data point of all) comes back as an error instead of an answer.

How FlightPowers helps

A tracker that starts from names

By-name lookup, no ID table

/hotel_by_name resolves the names your comp set is already written in. One optional area field handles the ambiguous ones, and /resolve gives you a cacheable Booking.com ID when you want permanence.

The fields a rate report needs

Price as a number, review_score, review_count, and room_type per property: enough to see not just who undercut you, but with what room and at what reputation.

Sold out is data, not an exception

Unavailable comes back as available: false with nulls in the same shape as a priced result. A competitor selling out is a row in the report, often the row that matters most.

Key workflows

The daily comp-set run

List the set. Property names plus the stay dates you price against: tonight, the weekend, the event window.
Resolve once, then track by ID. /resolve turns each name into its Booking.com ID; cache it and hit /hotel directly for room-level detail on every later check.
Normalise the currency. One currency value across the set makes the morning report a sorted column, not a conversion exercise.
Diff against yesterday. Store each run and alert on moves: a competitor dropping 15% for the weekend is a signal you want the same morning, not at month end.
Add the market view. proxy_country shows what each source market is quoted for the same set: the comp-set report and the parity report from one pipeline.

Questions, answered plainly

Do I need to map my comp set to internal property IDs first?: No. /hotel_by_name takes the hotel name a human would type (with an optional area field like “Antalya” to disambiguate) and resolves it for you. If you want stable references for a long-running tracker, call /resolve once per property to get its Booking.com ID, cache it, and hit /hotel directly on every check after that.
What does each check return?: The headline rate for your dates as both a string and a number, plus review_score, review_count, and room_type, and a booking link. Sold out or not found returns the same shape with available: false and nulls, so a scheduled tracker never branches on error formats.
How many requests does daily comp-set tracking cost?: One request per property per stay-date you track. A 5-property set checked daily for one target date is ~150 requests a month, inside the hotels Pro plan ($10/month, 2,000 requests). Tracking several stay dates or adding per-market checks with proxy_country scales the count linearly, which is what the larger tiers are for.

Related resources

Keep going

Hotel by Name

The lookup the tracker is built on

Competitive Sets

Checking a set of properties together

Hotel Price by Country

One property, several markets, free

Rate-parity guide

The per-market half of the job

Rate-parity monitoring

Same pipeline, different question

Stop checking your comp set in browser tabs

Live Booking.com rates for the properties you price against, by name, on a schedule, as data you can keep.

Get a key on RapidAPI →See pricing

Free tier: 10 requests/month. No card to try.