Why resolve first instead of calling /hotel_by_name every night?

/hotel_by_name re-runs name resolution on every call and returns one headline rate. /hotel takes the cached Booking.com ID directly and returns every room. Resolve once per competitor, confirm matched_name, cache the ID. After that the nightly job is pure data pulls.

What is a hotel_booking_id?

The Booking.com path ID for a property, for example cy/four-seasons-limassol. POST /resolve returns it together with matched_name, so you can confirm the match is the property you meant before caching it.

What does /hotel return for each room?

The room type, the meal plan (room_economy), the guest capacity, and the price both as a formatted string and as a number, for every room in the property, not a single headline rate.

Can I run the comp set from a specific market?

Yes. /hotel accepts proxy_country like every endpoint, so the same nightly sweep can price your set from the markets you compete in. The geo-pricing page shows a real captured spread between markets.

How do I catch a competitor selling out?

A scheduled /hotel_by_name check returns available: false with nulls (the same shape as ever) when a property has no rooms for the dates. Watch for price drops or the available flag flipping and alert on either.

How many requests does a nightly job cost?

One per property per market per night. A comp set of eight properties tracked from one market is eight requests a night. Size your plan quota from the table on this page.

Competitive-Set Tracking

Track your comp set, room by room

Resolve each competitor's name to its Booking.com ID once, then pull full room-level availability and pricing on a schedule.

/hotel returns every room (type, meal plan, guest capacity and price), not one headline rate
/resolve once per competitor; cache the ID and every later check goes direct
Add proxy_country to run the same sweep from the markets you compete in

Get a key on RapidAPI →All hotel endpoints

Free tier on RapidAPI. No card to try.

POST /hotel · from the API reference

{
  "hotel_booking_id": "it/boffenigoboutiquegarda",
  "checkin_date": "2026-05-01",
  "checkout_date": "2026-05-10",
  "booking_url": "https://www.booking.com/hotel/it/boffenigoboutiquegarda.html?...",
  "rooms": [
    {
      "room_type": "Classic Double Room",
      "room_economy": "Exceptional breakfast included",
      "guests": 2,
      "price_as_number": 2511,
      "price": "€ 2,511"
    },
    {
      "room_type": "Classic Double Room",
      "room_economy": "Exceptional breakfast included",
      "guests": 1,
      "price_as_number": 1739,
      "price": "€ 1,739"
    }
  ]
}

The documented response example from the listing's API reference. Shown as reference, not as a captured run.

The pattern

Resolve once, then go direct

A nightly comp-set job should not pay for name resolution on every call. Set it up once; after that, every check is a direct pull.

Step 1: once per competitor

POST /resolve turns the name a human would type into the Booking.com path ID. matched_name tells you what it actually matched, so a bad match is caught at setup time, not in your nightly numbers.

POST /resolve · from the API reference

// request
{ "hotel_name": "boffenigo boutique italy" }

// response
{
  "hotel_name": "boffenigo boutique italy",
  "hotel_booking_id": "it/boffenigoboutiquegarda",
  "matched_name": "Boffenigo Boutique Hotel & Spa"
}

Step 2: cache the ID

hotel_booking_id is stable: store it next to the competitor's name in your own config and never resolve again.

Step 3: every night

POST /hotel with the cached ID returns the full room list for the stay you track: every room type, meal plan, capacity and price, live from Booking.com at request time.

The lighter variant

When one headline rate per competitor is enough, schedule /hotel_by_name across the set instead: no setup step at all, at the cost of re-resolving on each call.

The nightly sweep, in full

python · one request per property

# IDs resolved once via POST /resolve, then cached (see step 1)
COMP_SET = {
    "Boffenigo Boutique Hotel & Spa": "it/boffenigoboutiquegarda",
    # ...the rest of your set
}

HEADERS = {
    "Content-Type": "application/json",
    "x-rapidapi-host": "booking-live-api.p.rapidapi.com",
    "x-rapidapi-key": os.environ["RAPIDAPI_KEY"],
}

for name, hotel_id in COMP_SET.items():
    r = requests.post(
        "https://booking-live-api.p.rapidapi.com/hotel",
        headers=HEADERS,
        json={
            "hotel_booking_id": hotel_id,
            "checkin_date": checkin,      # the stay you track
            "checkout_date": checkout,
            "currency": "EUR",
        },
    )
    for room in r.json()["rooms"]:
        store(name, room["room_type"], room["room_economy"],
              room["guests"], room["price_as_number"])

POST /hotel

Request fields

Required

hotel_booking_idstring

The Booking.com path ID, for example cy/four-seasons-limassol, from /resolve.

checkin_date / checkout_datestring

YYYY-MM-DD.

Optional

adults / childrenint

Default 2 / 0.

currencystring

Defaults to USD.

proxy_countrystring

Run the check from a specific market: geo-pricing shows a real captured spread.

free_cancellationboolean

Restrict to refundable rates.

Pricing

Size the plan from your comp set

Plan	Price / mo	Requests	$ / 1k req	Overage	Rate limit
BASIC	Free	10 / mo	—	hard cap	250 / min	Get this plan →
PRO	$10	2,000 / mo	$5.00	$0.006 / req	25 / min	Get this plan →
ULTRA	$20	6,500 / mo	$3.08	$0.003 / req	25 / min	Get this plan →
MEGA	$50	25,000 / mo	$2.00	$0.002 / req	50 / min	Get this plan →

Every plan includes every endpoint. You only choose volume and rate limit. Read from the live listing on 2026-08-26; the listing is authoritative.

Questions, answered plainly

Why resolve first instead of calling /hotel_by_name every night?: /hotel_by_name re-runs name resolution on every call and returns one headline rate. /hotel takes the cached Booking.com ID directly and returns every room. Resolve once per competitor, confirm matched_name, cache the ID. After that the nightly job is pure data pulls.
What is a hotel_booking_id?: The Booking.com path ID for a property, for example cy/four-seasons-limassol. POST /resolve returns it together with matched_name, so you can confirm the match is the property you meant before caching it.
What does /hotel return for each room?: The room type, the meal plan (room_economy), the guest capacity, and the price both as a formatted string and as a number, for every room in the property, not a single headline rate.
Can I run the comp set from a specific market?: Yes. /hotel accepts proxy_country like every endpoint, so the same nightly sweep can price your set from the markets you compete in. The geo-pricing page shows a real captured spread between markets.
How do I catch a competitor selling out?: A scheduled /hotel_by_name check returns available: false with nulls (the same shape as ever) when a property has no rooms for the dates. Watch for price drops or the available flag flipping and alert on either.
How many requests does a nightly job cost?: One per property per market per night. A comp set of eight properties tracked from one market is eight requests a night. Size your plan quota from the table on this page.

Explore more

More Hotels API

Geo-pricing

The same sweep, per market

Hotel by name

The no-setup variant

Destination search

Ranked properties + 24 filters

Hotels API hub

All four endpoints

Put your comp set on a schedule

Room-level Booking.com pricing for every property you compete with, live at request time, one request per property.

Get a key on RapidAPI →See pricing

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