Booking.com Hotels API
Live hotel rates, priced from any market
Search a destination or name a hotel; get Booking.com's live rates, review scores, room types and booking links as flat JSON.
- Live at request time: nothing is served from a cache, so the rate returned is the rate the guest would be quoted
proxy_country: price the same room from any market through a residential proxy- Name-based lookup:
/hotel_by_nametakes the name a human would type, no property IDs first
Free tier on RapidAPI. No card to try.
{
"destination": "Lisbon",
"checkin_date": "2026-10-09",
"checkout_date": "2026-10-12",
"adults": 2,
"currency": "EUR",
"filters": [
"review_score_8",
"free_cancellation"
]
}Short answer
What the FlightPowers Booking.com Hotels API returns
POST /v1/hotels/search takes a free-text destination and dates; POST /v1/hotels/by-name takes the name a person would type and resolves it for you. Both live on api.flightpowers.com, and are /search and /hotel_by_name on booking-live-api.p.rapidapi.com with a RapidAPI key. Every response carries live Booking.com rates for the whole stay, review score and count, room type and a booking link. Every endpoint also takes proxy_country.{
"destination": "Lisbon",
"checkin_date": "2026-10-09",
"checkout_date": "2026-10-12",
"applied_filters": [
"review_score_8",
"free_cancellation"
],
"properties": [
{
"name": "Avenue Hostel & Suites",
"price_string": "€215",
"price": 215,
"review_score": 8.2,
"review_count": 2392,
"room_type": "Twin Room with Shared Bathroom",
"nights": 3
},
{
"name": "Oscar Concept Apartments",
"price_string": "€452",
"price": 452,
"review_score": 9.2,
"review_count": 1828,
"room_type": "Standard Studio",
"nights": 3
}
]
}| Field | Type | Meaning | First property |
|---|---|---|---|
destination | string (request) | Free text: a city, a district, or a hotel name. The field is destination; location is rejected with a 400. | Lisbon |
price / price_string | number · string | The total for the stay, not per night, in the currency you asked for. Divide by nights for a nightly rate. | 215 · €215 |
nights | number | Length of the stay the price covers, echoed back on every property. | 3 |
review_score / review_count | number · number | Booking.com's score out of 10 and how many reviews it rests on. Either can be null on a property with too few. | 8.2 · 2392 |
room_type | string | The exact room the price belongs to. It is what makes two quotes comparable at all, across properties or across markets. | Twin Room with Shared Bathroom |
proxy_country | string (request) | Two-letter code that routes that one request through a residential proxy in that market, so you see the rate that market is quoted. | optional |
Nothing is cached. Every search runs against Booking.com at request time, which is also why response time tracks how much work the query is. filters takes any of the 24 documented values and comes back as applied_filters.
proxy_country is the one to look at if you price rooms for a living: same property, same dates, one field changed, and you can see what each market is quoted. That is rate-parity and geo-pricing monitoring, and it needs repeat sampling per market before a gap counts as real.
Endpoints
Four ways in, one subscription
Every hotels plan includes every hotels endpoint: you only choose volume and rate limit. Each page below shows a real captured request and what came back.
POST /search
Destination search
Free-text destination and dates in; ranked properties with live prices, review scores, room types and booking links out.
POST /hotel_by_name
Hotel by name
The name a human would type. Name resolution included: no property-ID step before you can ask anything.
proxy_country · every endpoint
Geo-pricing & rate parity
Price the same room from any market through a residential proxy. The page for revenue managers and BI teams.
POST /hotel + /resolve
Competitive-set tracking
Resolve a name to its Booking.com ID once, then pull the full room-by-room list on a schedule.
After flight data instead? The Google Flights API docs are documented to the same depth: one-way, round-trip, price insights and search status.
Request fields
The request surface, endpoint by endpoint
Dates are always YYYY-MM-DD, and every endpoint accepts proxy_country. Each dedicated page documents the response fields with captured values.
POST /search · required
destinationstringFree text: “Paris”, “Tokyo Shibuya”. Not location: that name 400s, with a message naming the fields it needs.
checkin_date / checkout_datestringThe stay. Required on every endpoint except /resolve.
POST /hotel_by_name · required
hotel_namestringThe name a human would type; area (optional) disambiguates generic names.
POST /resolve + POST /hotel · required
hotel_name → hotel_booking_idstring/resolve takes a name and returns the Booking.com path ID; /hotel takes that ID and returns the room-by-room list.
Optional · shared
adults / childrenintDefault 2 / 0.
currencystringDefaults to USD; prices and links follow it.
proxy_countrystringTwo-letter lowercase code: route the request through a residential proxy in that market. Accepted by every endpoint; the geo-pricing page shows a repeat-sampled run and how to read it.
filters · budget_per_nightstring[] · number/search only: the 24 facets below, plus a per-night cap in your currency.
free_cancellationboolean/hotel_by_name and /hotel: restrict to refundable rates.
filters
24 filters, matching the Booking.com UI
Pass any of these as a filters array on /search (the same facets Booking.com shows its own users), plus budget_per_night in whatever currency you set.
| Category | Filters |
|---|---|
| Cancellation | free_cancellation |
| Meals | breakfast_includedbreakfast_and_lunchbreakfast_and_dinnerall_meals_includedall_inclusive |
| Facilities | free_wifiswimming_poolgymparkingfront_desk_24h |
| Review score | review_score_7review_score_8review_score_9 |
| Room facilities | private_bathroomair_conditioning |
| Property rating | stars_3stars_4stars_5 |
| Travel group | pets_allowedadults_only |
| Activities | sauna |
| Guest reviews | very_good_breakfast |
| Payment | accepts_online_payment |
Why this one
Common gaps in other hotel APIs
The problems developers hit with general-purpose hotel data sources, and what this API does about each.
| The problem | How this API handles it |
|---|---|
| You need an internal property ID before you can ask anything | /hotel_by_name accepts the name a human would type |
| One price per hotel, no room breakdown | /hotel returns every room with its type, meal plan, capacity and price |
| Prices are cached and drift from what the guest sees | Every request is live against Booking.com |
| No way to see market-specific pricing | proxy_country routes through a residential proxy in any country |
| A thin slice of the site’s filters | 24 filters plus budget_per_night, matching the Booking.com UI |
| Errors and sold-out come back in different shapes | Consistent available: false plus nulls, so parsing never branches |
Pricing
Every plan carries every 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
- Are prices cached?
- No. Every query hits Booking.com live at request time, so the rate that comes back is the rate a guest would be quoted at that moment. The honest trade-off: response time tracks how much work Booking.com has to do for the query.
- What does proxy_country do?
- Every endpoint accepts proxy_country, a two-letter lowercase country code ("us", "de", "il"). The request routes through a residential proxy in that country, so you see the rates Booking.com quotes that market. Leave it out and the request goes through the global residential pool.
- Which endpoint do I start with?
- POST /search for a destination, POST /hotel_by_name for one property by its name (resolution included), and POST /resolve followed by POST /hotel when you want the full room-by-room list for a property you check repeatedly.
- What fields does /search require?
- destination (free text: "Paris", "Tokyo Shibuya"), checkin_date, and checkout_date in YYYY-MM-DD. Note the field is destination, not location. Sending location returns a 400 with a clear message naming the fields it needs.
- How do sold-out and not-found come back?
- As the same response shape with "available": false and nulls in the price fields, so your parser never has to branch on an error format.
- What does the free tier include?
- Every endpoint, 10 requests per month, hard cap. That verifies your key and your integration. It is not enough volume to evaluate data quality. Paid plans start at $10/month on RapidAPI.
Live Booking.com rates, one key away
Destination search, name lookup, room-level pricing and per-market rates. One subscription covers every endpoint.
Free tier: 10 requests/month. No card to try.