What this API does and who it is for
Hotels com Provider wraps the Hotels.com catalogue — reportedly covering more than 325,000 properties across roughly 19,000 locations — and exposes it through a REST interface. The data you can pull includes hotel listings with real-time room prices, property photos, amenity details, and guest reviews with scores.
The primary audience is developers building travel-adjacent products: aggregator sites, trip-planning apps, price-comparison tools, or internal tools that need hotel inventory without negotiating a direct data partnership. If your goal is a consumer-facing product that looks and behaves like Hotels.com or Booking.com, this API provides most of the underlying data you would need.
Authentication is handled entirely through RapidAPI. Every request must carry two headers — X-RapidAPI-Key (your personal key) and X-RapidAPI-Host set to hotels-com-provider.p.rapidapi.com. There is no OAuth flow or separate token exchange; once you subscribe on RapidAPI, you can start making calls immediately.
Endpoint walkthrough
The API currently exposes 15 endpoints spread across two versions (v2 and v3). The general workflow follows a predictable pattern: look up a region ID, run a hotel search, then drill into individual properties for details, room offers, and reviews.
Discovering regions and domains
Before searching for hotels you need two identifiers: a domain code (e.g., US, GB, DE) that controls currency and regional settings, and a region_id that represents the destination. The GET /v2/domains endpoint returns the full list of supported domains with their associated currencies and locales, which is worth caching locally rather than fetching on every user request.
To find a region_id, call GET /v2/regions with a free-text query parameter (a city name, neighborhood, or even a hotel name) plus the domain and locale you want. The response returns matching destinations with their IDs, which you then feed into the search step.
There is also a utility endpoint, GET /v2/meta/convert/slug-id, that converts a Hotels.com URL slug (the ho219115 portion of a Hotels.com URL) into the internal hotel ID the API uses. This is handy when you need to deep-link from an existing Hotels.com page into your own application.
Searching for hotels
Two search endpoints exist: the v2 version (GET /v2/hotels/search) and the newer v3 version (GET /v3/hotels/search). The documentation marks v2 as deprecated, so new integrations should prefer v3. Both accept the same core parameters: region_id, checkin_date, checkout_date, adults_number, domain, locale, and sort_order.
Sort order options include PRICE_LOW_TO_HIGH, REVIEW, RECOMMENDED, DISTANCE, PROPERTY_CLASS, and PRICE_RELEVANT, which gives you reasonable control over result ordering for different UX patterns.
Optional filters let you narrow results by star rating, minimum/maximum price, minimum guest rating (scale of 7–9 in the parameter), lodging type (e.g., HOTEL, HOSTEL), meal plan, amenities such as WIFI or PARKING, payment type (PAY_LATER, FREE_CANCELLATION), and children's ages for family travel searches. Pagination goes up to 500 pages.
Property details, rooms, and reviews
Once you have a hotel ID, four endpoint families give you deeper data:
- Summary (
/v2/hotels/summary,/v3/hotels/summary) — high-level property overview - Info (
/v2/hotels/info,/v3/hotels/info) — detailed property information including photos and amenities - Offers / Rooms (
/v2/hotels/offers,/v3/hotels/offers) — live room availability and pricing for the specified dates - Reviews (
/v2/hotels/reviews/list,/v2/hotels/reviews/scores,/v2/hotels/reviews/summary) — guest review content, overall scores, and summary statistics
Reviews can be sorted by HIGHEST_TO_LOWEST_RATED, LOWEST_TO_HIGHEST_RATED, NEWEST_TO_OLDEST, or NEWEST_TO_OLDEST_BY_LANGUAGE, which is useful if your product surfaces reviews in multiple languages.
Pricing breakdown
| Plan | Monthly price | Requests/month | Rate limit | Overage |
|---|---|---|---|---|
| BASIC | $0 | 600 | 5 req/sec | — |
| PRO | $11 | 14,000 | 5 req/sec | $0.0020/req |
| ULTRA | $28 | 74,000 | 7 req/sec | $0.0020/req |
| MEGA | $49 | Unlimited | 10 req/sec | — |
The free BASIC tier is genuinely useful for building and testing a prototype — 600 requests is enough to validate your integration logic. However, consider how many API calls a single user session requires: a region lookup, a hotel search page, and then viewing one hotel's detail, rooms, and reviews could consume five or more requests. At that ratio, 600 monthly requests supports only around 100–120 complete user sessions before the quota runs out.
The PRO tier at $11/month is the natural first paid step for a small side project or internal tool. The $0.0020 overage rate means an unexpected traffic spike won't immediately break the bank, but it can add up if your application scales without upgrading the plan.
MEGA's unlimited requests at $49/month makes the most sense for a production application with steady traffic, since it eliminates the need to track overage costs and provides the highest rate ceiling at 10 requests per second.
Practical use cases
Travel aggregator front end — the combination of region search, hotel search with filters, room offers, and reviews gives you everything needed to replicate the core browse-and-compare loop of a booking site. You would need to add your own booking flow or affiliate links on top.
Price-monitoring tool — you can poll the offers endpoint on a schedule to track price changes for specific properties over time, alerting users when rates drop below a threshold.
Itinerary or trip-planning app — pull hotel summaries and reviews to suggest accommodation options alongside other travel content, without needing a full booking integration.
Content enrichment — inject hotel photos, amenity lists, and review scores into content that references specific properties, using the slug-to-ID converter to match Hotels.com URLs you already have.
Limitations and things to check before integrating
Latency — the reported average latency is 1,645 ms. For endpoints that block page rendering (like a hotel search result list), that is slow enough to require explicit loading states in your UI and possibly server-side caching of common searches. Do not assume sub-second response times.
Success rate — a 93% average success rate means roughly 1 in 14 requests will fail. Build retry logic and graceful error handling from the start, not as an afterthought.
v2 deprecation — several v2 endpoints are marked deprecated in favor of v3 equivalents. The review endpoints (/v2/hotels/reviews/*) currently have no v3 counterparts listed, so those remain on v2. Keep an eye on the documentation for any endpoint lifecycle changes that could affect production integrations.
Free-tier constraints — the 5 req/sec rate limit applies even on paid PRO, so if your application makes parallel requests (e.g., fetching details for multiple hotels simultaneously), you will need to throttle client-side.
Data source dependency — this API proxies Hotels.com data, so its availability and accuracy are tied to the upstream source. Changes to Hotels.com's own API or data structure can cause disruptions that are outside the provider's direct control.
Getting started
- Create or log in to a RapidAPI account and subscribe to Hotels com Provider on the BASIC (free) plan.
- Grab your
X-RapidAPI-Keyfrom the RapidAPI dashboard. - Call
GET /v2/domainsto familiarize yourself with available domain and locale combinations. - Use
GET /v2/regionsto resolve a destination name to aregion_id. - Run
GET /v3/hotels/searchwith thatregion_id, your check-in/out dates, and at least one adult. - Take a hotel ID from the search results and hit
/v3/hotels/offersto see live room pricing.
The provider offers support via email at [email protected] and a Telegram channel at t.me/api_tipsters. The same provider also lists other travel APIs at rapi.one/travel, so if you need complementary data (flights, car rentals) it is worth checking their portfolio for compatible endpoints.