How to get every room rate for one hotel

Published September 5, 2026

Short answer: Resolve the property name once with POST resolve on booking-live-api.p.rapidapi.com to get a stable hotel_booking_id, then call the rooms endpoint with that ID plus checkin_date and checkout_date on every check. The rooms response lists every room type with its own price_as_number for the whole stay, not the single headline rate a name lookup returns.

A name lookup gives you the property's headline rate, which is one room out of however many it sells. That is the right answer for "what does this hotel cost". It is the wrong answer for a comp-set tracker, a rate-parity check, or anything where the interesting movement is a suite going on sale while the standard double sits still.

For that you want the room list, and it is a two-step the first time and a one-step after.

Step one, once per property: resolve the name

curl -X POST "https://booking-live-api.p.rapidapi.com/resolve" \
  -H "Content-Type: application/json" \
  -H "x-rapidapi-host: booking-live-api.p.rapidapi.com" \
  -H "x-rapidapi-key: $RAPIDAPI_KEY" \
  -d '{"hotel_name": "boffenigo boutique italy"}'

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

Note what went in: three vague words, not a catalogue entry. matched_name tells you what it resolved to, so you can eyeball the match once and then stop worrying about it.

Step two, on every check: the rooms

hotel_booking_id is the Booking.com path ID and it is stable. Cache it and call the rooms endpoint directly from then on. Required with it: checkin_date and checkout_date. Optional: adults, children, currency, proxy_country, free_cancellation.

A real response, trimmed to one room for width:

{
  "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"
    }
  ]
}

price_as_number is the total for the whole stay, nine nights in this capture, not a nightly rate. Divide by your own night count rather than trusting a per-night field that does not exist. room_economy is the free-text line Booking.com shows next to the room, which is where breakfast and cancellation terms usually live, so treat it as a label rather than a structured field.

The rule that saves you a plan tier

Resolve once, cache the ID, then never resolve again. A tracker watching 50 properties daily that resolves each name every run is doing 50 avoidable requests a day. Resolution is the step that can change, and it changes about as often as a hotel renames itself.

What are the limits?

One property, one date pair, one call. No date-range expansion and no property list here. Pricing a range means a request per date.

Room availability moves faster than property availability. A property can be bookable while the specific room you are tracking is not, so key your history on the room type and expect gaps rather than treating a missing row as a price drop.

Rates are live and perishable. Every call hits Booking.com at request time. Caching the price for a day turns a real number into a wrong one. Cache the ID, not the rate.

A key with every endpoint on it comes from the RapidAPI listing, free plan included. Ten requests is enough to resolve a property and pull its rooms twice.

Related

• Hotel prices by hotel name: the one-call headline rate
• Do hotel prices change by country?: proxy_country, with a repeat-sampled run
• How to monitor hotel rate parity: the scheduled version
• Hotel comp-set tracking: what this is usually built for