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.

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
}

Short answer

What a hotel-by-name lookup returns

POST /v1/hotels/by-name on api.flightpowers.com (the same endpoint is /hotel_by_name on booking-live-api.p.rapidapi.com with a RapidAPI key) takes hotel_name as free text plus checkin_date and checkout_date, with an optional area to disambiguate. It resolves the name itself, so there is no property-ID step, and returns one flat object with availability, the live rate for the stay and a booking link. It is POST only; a GET returns 405.

“Kremlin Palace”, Antalya, 2026-10-05 → 2026-10-10 · trimmed · captured 2026-08-26

{
  "name": "Kremlin Palace",
  "available": true,
  "price_string": "$1319",
  "price": 1319,
  "nights": 5,
  "room_type": "Superior Double or Twin Room",
  "review_score": 8.4,
  "review_count": 803,
  "adults": 2,
  "children": null
}

Field	Type	Meaning	Above
`available`	boolean	Sold out and not found both return this object with available: false, so your parsing never has to branch on which happened.	true
`name`	string \| null	The property the name resolved to, as Booking.com spells it. Check it before trusting a match on a generic name.	Kremlin Palace
`price / price_string`	number · string	The total for the stay, not per night, as a number and as a display string. Divide by `nights` for a nightly rate.	1319 · $1319
`nights`	number \| null	The stay the price covers, derived from your two dates and echoed back.	5
`room_type`	string \| null	The exact room the rate belongs to. It is the field that makes two quotes comparable at all.	Superior Double or Twin Room
`review_score / review_count`	number \| null · number \| null	Booking.com's score out of 10 and how many reviews back it. Either can be null on a property with too few.	8.4 · 803

area only widens the search query to "<hotel_name>, <area>"; the name matching still runs on hotel_name alone, which is why a generic name plus a city resolves the way a person would expect.

The capture above was one of three requests that differed only in proxy_country, which every hotels endpoint accepts. That is the basis of rate-parity and geo-pricing monitoring. This property priced within a dollar across all three markets, which is also an answer.

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.

Response

Every response field

Values in brackets are from the captured Kremlin Palace run above (the us request). Real output, not invented examples.

namestring | null

The matched property's listed name: "Kremlin Palace" in the capture. null when nothing matched.

availableboolean

The one field to branch on. false means sold out for the dates or not found, and the price fields are null; there is no separate error shape.

price / price_stringnumber · string | null

The stay total, twice: a number (1319) and the formatted version ($1319), in the currency you set. Total for all 5 nights, not per night: divide by nights for the nightly rate.

review_score / review_countnumber | null · number | null

Booking.com's guest score and review count: 8.4 from 803 reviews in the capture. review_score can be null even on an available property: the Rixos Sungate capture on the geo-pricing page returned null score with 375 reviews counted, so null-check it independently of available.

room_typestring | null

The room the price is for: "Superior Double or Twin Room" in the capture.

image_urlstring | null

A property thumbnail hosted by Booking.com, ready for an <img> tag.

linkstring | null

A working Booking.com URL for exactly this room, these dates, and this party.

nights / adults / childrennumber | null

The stay as priced: nights computed from the dates (5 in the capture), adults as applied (2, the default since the request sent none), and children, null when the request did not send any.

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	—	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 →

Swipe the table sideways for overage and rate limits.

Every plan on this API includes all of its endpoints; flights and hotels are separate subscriptions. Read from the live listing on 2026-09-11; 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 how to sample it properly before calling a difference a finding.
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, sampled per market

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.