FlightPowers: find one hotel by name
find_hotel_by_nameFlightPowers single-property lookup: live Booking.com availability and pricing for one named property. Input: the hotel name a person would type (adding the city helps when a chain has many properties) plus check-in and check-out dates -- no internal property ID needed, the server resolves the name. Returns the property's price, review score, room type, latitude/longitude and a booking link. It checks one specific hotel, or tracks a single property's price over time.
A date range and a nights value price several stays in one call, checkin_date_from, checkin_date_to and nights (a number, or a list like [2, 3, 7]) replace a fixed checkin_date/checkout_date, and this property is priced for every check-in date -- a rate calendar for one hotel. The answer is stays, one entry per date with that date's price and per-night rate, plus cheapest_overall. Each stay is one search; max_searches caps it, and a range that expands past the cap is sampled evenly across the calendar and says so in search_coverage. With the caller's own key the cap rises by itself to cover a month-sized range. On the free sign-in allowance (10 searches a day, one per stay) a range larger than what is left today is refused before anything runs; a range within what is left runs, and a wider range needs the caller's own key.
price_as_seen_from prices the stay as a shopper resident in that country would see it. Gaps are real but usually modest and property-dependent, and rates move between calls, so a gap holds only when it repeats over a few calls per country on this same property.
Rates go stale within minutes: a current price comes from a new search, not from an earlier result.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | Number of adult guests. | |
| nights | No | How many nights to stay, as a number (3) or a list ([2, 3, 7]) to price several lengths. Derives the check-out date from each check-in date, so it replaces checkout_date rather than joining it. | |
| verbose | No | Returns the property exactly as the source sent it, image URL and the full tracking link included. Off by default: the row leaves out the image URL, the booking link keeps only its stay parameters, and price_per_night is added. | |
| children | No | Number of children sharing the room. | |
| currency | No | ISO currency code for the prices returned, e.g. "usd". | |
| hotel_name | Yes | The property name a person would type, e.g. "Hotel Artemide". Adding the city ("Hotel Artemide Rome") disambiguates a chain with many properties. No internal property ID is needed. | |
| checkin_date | No | First night of the stay, "YYYY-MM-DD". With checkout_date it prices one stay; checkin_date_from plus checkin_date_to give a rate calendar instead. | |
| max_searches | No | The searches this call may make, up or down. One stay is one request; with the caller's own key the cap rises by itself to cover a month-sized request, and anything past the cap in force is sampled evenly across the calendar rather than cut short at the front. | |
| checkout_date | No | Departure morning, "YYYY-MM-DD". Must be after checkin_date. Mutually exclusive with `nights`. | |
| checkin_date_to | No | Last check-in date of the range, "YYYY-MM-DD". | |
| checkin_date_from | No | First check-in date of a range, "YYYY-MM-DD". Needs checkin_date_to and nights, and prices this property on every check-in date in the range -- one call, a rate calendar. | |
| price_as_seen_from | No | Two-letter country code, e.g. "de". Prices the stay as a shopper resident in that country would see it. Rates move between calls and gaps are usually modest and property-dependent, so a gap holds only when it repeats over a few calls per country on this same property. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| stays | No | One entry per stay the REQUEST asked for, in request order, present whether or not that stay was priced. Only on a date-range search (checkin_date_from / checkin_date_to / nights); a single stay does not carry it. Coverage comes from here, not from `results`: `results` holds the full property list for the CHEAPEST stay only, so a stay missing from it looks identical to a stay that had nothing. `reason` says which kind of hole an unpriced stay is: 'no_availability' (searched, answered, nothing came back), 'no_price' (properties came back, none carried a price), 'search_failed' (the search errored, so nothing is known -- not 'no rooms') or 'not_searched' (the per-call fan-out cap sampled it away). Counts are null rather than zero on those last two, because zero reads as 'nothing there' and neither case knows that. | |
| message | No | ||
| partial | No | Present when some stays failed but others were priced. Plain text saying how much of the request the answer covers. | |
| results | Yes | The properties found, in the order Booking.com returned them. An empty array is only meaningful when search_status is 'empty'. By default at most `limit` rows (10), the cheapest always included, each the source's own object without image URLs, with the booking link cut to its stay parameters and price_per_night (the stay total divided by its nights) added; `verbose: true` returns the source's rows untouched. latitude and longitude are the property's WGS84 coordinates in decimal degrees, from Booking.com, null when it publishes none. | |
| api_usage | No | With the caller's own key: what this call cost their RapidAPI plan, and what remains on it. On a free signed-in search (`trial` present): the day's free-search counter instead, and no plan figures -- the search ran on FlightPowers' key and nothing is billed to the user. Present on every response that reached the upstream, including a degraded one. | |
| signup_url | No | Where the caller subscribes or changes plan. | |
| result_count | No | ||
| results_note | No | Present when `limit` left properties out: how many were found and how to see more. | |
| needs_api_key | No | True when no usable RapidAPI key arrived with the call, or the upstream rejected the one that did. No search was run and nothing was billed; signup_url and message describe the fix. | |
| results_total | No | How many properties the source returned for the stay in `results`, before `limit`. Absent with `verbose: true` and no `limit`, where every row is in `results`. | |
| search_status | No | Date-range searches only, except 'trial_exhausted'. 'ok': every stay searched was priced. 'empty': they all answered and none had priced availability -- a real answer. 'partial': some stays were priced and some errored. 'degraded': every stay errored, so nothing is known; safe to retry. 'trial_exhausted': the free signed-in allowance on this server is spent for today, so nothing was searched and nothing was billed; it renews at 00:00 UTC and the caller's own RapidAPI key, once connected, removes the cap. Retrying does not help. 'quota_exceeded': the search was refused because the caller's remaining allowance or plan quota cannot cover the number of combinations asked for; combos_requested and combos_allowed_now carry the two numbers. Nothing was searched beyond what it cost to read the quota. Retrying the same search does not help; a request with fewer dates or nights, or a larger plan, does. | |
| applied_filters | No | Which of the requested filters the upstream actually applied. Untyped: the shape is the upstream's, echoed through. | |
| quota_exhausted | No | True when the caller's RapidAPI plan has no requests left for the current period. | |
| search_coverage | No | What was actually priced on a date-range search. Present whether or not the request was truncated, so the answer's basis is on the record either way. | |
| cheapest_overall | No | The cheapest stay across everything priced, or null when nothing was. `results` holds this stay's full property list. | |
| results_for_stay | No | Which stay `results` belongs to on a date-range search, or null when nothing was priced. `results` holds this stay's properties only, not the whole range's. |