FlightPowers: search hotels
search_hotelsFlightPowers hotel search: live Booking.com availability and nightly prices for a destination and date range. Input: a free-text destination the way a person would write it ("Rome", "Tokyo Shibuya"), plus check-in and check-out dates. Returns each property's price, review score, room type, location, latitude/longitude and a booking link: 10 properties by default, the cheapest always among them; limit asks for more or fewer, and verbose: true returns the source's full rows.
price_as_seen_from, a two-letter country code, prices the same stay the way a shopper resident in that country would see it. Gaps are real but usually modest and property-dependent, and rates move between calls, so one call per country is not evidence of a gap; a parity check holds one named property fixed and calls each country a few times.
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 every check-in date is priced separately. The answer is stays -- one entry per stay with its cheapest property, per-night price and median -- plus cheapest_overall, and the full property list for the cheapest stay only. Each stay is one search; max_searches caps it, and a request that expands past the cap is sampled evenly across the range 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.
Rates go stale within minutes: a current price comes from a new search, not from an earlier result.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many properties to return (default 10; a stay has about 25). They come in the order Booking.com returned them, and the cheapest is always included. results_total says how many there were. | |
| adults | No | Number of adult guests. Defaults to the upstream default when omitted. | |
| 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. | |
| filters | No | Property filters to apply, e.g. ["free_cancellation", "breakfast_included"]. An unknown name is rejected with the list of valid ones rather than being ignored. | |
| verbose | No | Returns each property exactly as the source sent it, image URLs and the full tracking link included, and every property unless limit is set. Off by default: rows leave out image URLs, 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". | |
| destination | Yes | Where to stay, in free text the way a person would write it, e.g. "Rome" or "Tokyo Shibuya". A city, district, landmark or region all work; no internal location 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 price a range of check-in dates instead. | |
| max_searches | No | The searches this call may make, up or down. One stay is one request, so a 30-day range at two lengths is 60 and a month at three is 93 -- with the caller's own key the cap rises to cover a request that size by itself. A lower value spends less and a higher one (hard maximum 200) covers a wider grid; either way the range 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". | |
| budget_per_night | No | Only properties at or below this nightly price, in `currency`, are returned. | |
| checkin_date_from | No | First check-in date of a range, "YYYY-MM-DD". Needs checkin_date_to and nights, and prices one stay per check-in date in the range. | |
| price_as_seen_from | No | Two-letter country code, e.g. "de". Prices the stay through a residential connection in that country, so the result is what a shopper resident there would be quoted. A rate-parity check holds one named property fixed and calls each country a few times, because rates move between calls and one call per country can show a gap that is not there. Without it the price is neutral. |
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. |