What if two hotels share a name?

Pass area, a city or region like "Budapest" or "Antalya". The search query becomes " , " while name matching still uses only hotel_name, so the area steers the search without polluting the match.

What comes back when the hotel is sold out or not found?

The same response shape, with "available": false and nulls in the price fields. There is no separate error format to branch on: check one boolean and move on.

Do I ever need a property ID?

Not on this endpoint: resolution from name to property happens inside the call. If you check the same property repeatedly, the ID-based path is faster to build on: POST /resolve turns the name into a Booking.com ID once, then POST /hotel returns the full room list directly. The competitive-set tracking page covers that pattern.

Can I price the same hotel from another market?

Yes. proxy_country works here like on every endpoint. The captured example on this page was one of three requests that differed only in proxy_country; the geo-pricing page shows the full comparison.

Is the price per night?

No: price is the total for the stay, and the response carries nights so a nightly rate is one division away.

Hotel by Name API

The name a human would type

Most hotel APIs make you resolve an internal property ID before you can ask anything useful. /hotel_by_name does the resolution for you.

Send hotel_name + dates: availability, live price and a booking link come back
area disambiguates generic names: the match still runs on the name alone
Sold out and not found return the same shape with available: false, so parsing never branches

Get a key on RapidAPI →All hotel endpoints

Free tier on RapidAPI. No card to try.

POST /hotel_by_name · booking-live-api

captured run · 2026-08-26

{
  "hotel_name": "Kremlin Palace",
  "area": "Antalya",
  "checkin_date": "2026-10-05",
  "checkout_date": "2026-10-10",
  "currency": "USD",
  "proxy_country": "us"
}

Replays the captured request: free, no account, nobody's quota.

{
  "name": "Kremlin Palace",
  "available": true,
  "price_string": "$1319",
  "price": 1319,
  "review_score": 8.4,
  "review_count": 803,
  "room_type": "Superior Double or Twin Room",
  "image_url": "https://cf.bstatic.com/xdata/images/hotel/square240/501059778.webp?k=d798971642ff387e93760479b1a1a3ba4eb9c8ccb2c1f71f6c2fe9bca3c25d74&o=",
  "link": "https://www.booking.com/hotel/tr/kremlin-palace.html?aid=304142&label=gen173nr-10CAQoggJCC2hvdGVsXzg2NDk0SDFYBGixAogBAZgBM7gBB8gBDNgBA-gBAfgBAYgCAagCAbgCy4a71AbAAgHSAiRlYzFiZDEwZC03NmY5LTQ4ZmYtYTU5MC0yMDg4N2ZjZWVlYznYAgHgAgE&ucfs=1&arphpl=1&checkin=2026-10-05&checkout=2026-10-10&dest_id=86494&dest_type=hotel&group_adults=2&req_adults=2&no_rooms=1&group_children=0&req_children=0&hpos=1&hapos=1&sr_order=popularity&srpvid=22014b651d791bf4&srepoch=1787741005&all_sr_blocks=8649413_0_2_85_0&highlighted_blocks=8649413_0_2_85_0&matching_block_id=8649413_0_2_85_0&sr_pri_blocks=8649413_0_2_85_0__101768&from=searchresults",
  "nights": 5,
  "adults": 2,
  "children": null
}

Request fields

Name and dates in, one flat object out

The captured run above sent “Kremlin Palace” with area “Antalya” (a generic name a plain search could mismatch) and got the property back with its live rate for the stay.

Required

hotel_namestring

Free text: the name a person would type. Matching runs on this field only.

checkin_date / checkout_datestring

YYYY-MM-DD.

Optional

areastring

City or region to disambiguate generic names, like “Budapest” or “Antalya”. The search query becomes "<hotel_name>, <area>" while name matching still uses only hotel_name.

adults / childrenint

Default 2 / 0.

currencystring

Defaults to USD.

proxy_countrystring

Price the property from another market: the geo-pricing page compares three markets with this exact request.

free_cancellationboolean

Restrict to refundable rates.

One shape, always

the response shape

{
  name:          string | null,
  available:     boolean,   // false = sold out or not found
  price_string:  string | null,   // total for the stay
  price:         number | null,
  review_score:  number | null,
  review_count:  number | null,
  room_type:     string | null,
  image_url:     string | null,
  link:          string | null,   // booking link for this room & dates
  nights:        number | null,
  adults:        number | null,
  children:      number | null
}

Sold out and not-found return this same shape with available: false and nulls, never a different error format. Your integration checks one boolean; there is no second code path to test.

Repeated checks

The ID-based fast path

Name resolution is convenience you pay for on every call. If you check the same property on a schedule, resolve once and go direct instead.

POST /resolve

Turns a hotel name into its Booking.com ID, for example cy/four-seasons-limassol. Call it once per property and cache the ID.

POST /hotel

Takes that ID and returns the full room-by-room list (room type, meal plan, guest capacity and price for each) instead of a single headline rate.

The competitive-set tracking page walks through the resolve-once-then-poll pattern end to end.

Pricing

Every plan carries this endpoint

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

What if two hotels share a name?: Pass area, a city or region like "Budapest" or "Antalya". The search query becomes "<hotel_name>, <area>" while name matching still uses only hotel_name, so the area steers the search without polluting the match.
What comes back when the hotel is sold out or not found?: The same response shape, with "available": false and nulls in the price fields. There is no separate error format to branch on: check one boolean and move on.
Do I ever need a property ID?: Not on this endpoint: resolution from name to property happens inside the call. If you check the same property repeatedly, the ID-based path is faster to build on: POST /resolve turns the name into a Booking.com ID once, then POST /hotel returns the full room list directly. The competitive-set tracking page covers that pattern.
Can I price the same hotel from another market?: Yes. proxy_country works here like on every endpoint. The captured example on this page was one of three requests that differed only in proxy_country; the geo-pricing page shows the full comparison.
Is the price per night?: No: price is the total for the stay, and the response carries nights so a nightly rate is one division away.

Explore more

More Hotels API

Geo-pricing

This request, three markets

Competitive-set tracking

Resolve once, poll /hotel

Destination search

Ranked properties + 24 filters

Hotels API hub

All four endpoints

Price any hotel by its name

No ID lookups, no second error format: one POST with a name and dates, one flat object back.

Get a key on RapidAPI →See pricing

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