I build and run a travel platform that sells more than flights, so this post is about what the integration looks like in practice, not in the sales deck. The booking call is the easy part. Most of the effort goes into data: getting clean, trustworthy hotel content in front of the user and making sure what they book is exactly what they were shown.
Where hotel inventory comes from
Before any code, decide where your rooms come from. There are three broad sources, and they differ in coverage, pricing model and integration effort.
| Source | What you get | Good fit when |
|---|---|---|
| GDS hotel content | Hotels through the same Amadeus, Sabre or Travelport connection you use for flights, mostly chain properties | You already have a GDS contract and your customers are corporate or chain-hotel travellers |
| Bedbanks / wholesalers | Large aggregated inventories of chain and independent hotels, often at net rates you mark up | You want broad leisure coverage and control over your margin, which suits most B2B agent portals |
| Direct connections | Specific chains or properties connected directly or via a channel manager, at contracted rates | You have volume in particular destinations or negotiated deals with particular hotels |
For most portals the practical starting point is one bedbank (for broad leisure coverage and a clean net-rate margin model) or the GDS you already have (if your traffic is mostly corporate and chain hotels). Direct connections come later, once you know which destinations and properties actually drive your bookings. Like GDS access, supplier access is a commercial agreement: expect an application, a certification process and negotiated terms rather than a public sign-up. I cover how that works on the flight side in Sabre vs Amadeus vs Travelport.
What makes hotels harder than flights
1. Static content vs live availability
Hotel APIs usually split data into two kinds. Static content covers the hotel's name, address, coordinates, star rating, photos, descriptions and amenities. It changes rarely, and you're expected to download it in bulk and store it yourself. Dynamic content is availability and rates for specific dates, which you fetch live. If you try to pull photos and descriptions on every search, the results page will be slow and you'll hit rate limits. The standard design is a local content store, refreshed on a schedule, with live calls only for price and availability.
2. Hotel mapping
As soon as you have a second supplier, the same physical hotel arrives twice, with different IDs, slightly different names ("Hotel Grand Plaza" vs "Grand Plaza Hotel & Spa"), different addresses and slightly different coordinates. Without mapping, your results show one hotel three times at three prices, which looks broken to users. With mapping, you show it once and offer the best rate across suppliers. Mapping combines matching rules (name similarity, distance between coordinates, address and chain codes) with a mapping service or dataset, plus a manual review queue for edge cases. It isn't a one-off job. New properties appear and existing ones change, so it needs ongoing maintenance.
3. Rooms and board basis aren't standardised
Flights have fare classes and codes that mean the same thing everywhere. Hotel rooms don't. One supplier's "Deluxe King" is another's "Superior Double, 1 King Bed". Board basis (room only, breakfast, half board, all inclusive) is described inconsistently too. You need to normalise these into your own model so users can compare like with like, and so your filters ("free cancellation", "breakfast included") actually work across suppliers.
4. The price moves: always re-check before booking
Hotel search results are often cached or approximate, and real rates and room allocation change all the time. That's why hotel APIs have a separate rate-check / pre-book step that confirms the exact price and policy for the chosen room before you commit. Your booking flow should be: search → select room → re-check rate → show the confirmed price and policy → take payment → book → confirm. If the price has changed or the room is gone, tell the user clearly and offer alternatives. Booking at a stale search price is how portals end up absorbing losses or cancelling on customers. It's the same price-drift problem as flights, and I explain the general pattern in integrating multiple GDS providers into one booking engine.
5. Cancellation policies are per rate
Every hotel rate carries its own cancellation policy: free until a certain date, partial penalty after, non-refundable, and so on. These deadlines are usually in the hotel's local time. Your portal has to show the policy clearly before booking, store it exactly as confirmed, and enforce it on cancellation. In a B2B portal, the penalty also has to flow correctly through agent wallets and refunds. Getting this wrong costs money directly, so it deserves more testing than the search screen.
6. Taxes, fees and currency
Suppliers differ on whether rates include taxes, which fees are paid at the property (city or resort fees), and which currency they price in. Show the user a clear total, flag anything payable at the hotel, and handle currency conversion consistently, with your markup applied at a defined point. Mixing inclusive and exclusive rates in one results list without normalising them makes your cheapest option look cheaper than it really is.
How it fits into your portal's architecture
If your portal already has a clean supplier abstraction layer (one internal interface for search, price and book, with providers behind it), hotels become another product type behind that layer. You reuse what you've already built: users and agent logins, wallets, markup and commission rules, payments, invoicing and the admin panel. The new pieces are hotel-specific: the static content store, the mapping service, the room and board normalisation, and hotel booking management (vouchers, amendments, cancellations).
If flights were wired directly into the application, adding hotels is the right time to introduce that layer. You'll almost certainly want a second hotel supplier within a year, for coverage or better rates, and adding it is far easier behind an interface. If you're on Amadeus already, its hotel APIs are one natural first source. I've walked through the flight side of that in integrating the Amadeus API into a B2B travel portal.
A sensible way to launch
Don't try to launch with every supplier, every destination and every feature. Here's a phased plan that works:
- Phase 1: one supplier, your top destinations, search → rate check → book → voucher → cancel, with clear policies and totals. Reuse your existing payments, wallets and markup.
- Phase 2: static content store and caching tuned for speed, better filters (price, stars, board basis, free cancellation), and admin tools for bookings and amendments.
- Phase 3: a second supplier with mapping and best-rate selection, then direct connections where your volume justifies them.
This gets hotels earning quickly and puts off the expensive part (mapping across suppliers) until you know you need it. For a sense of how this affects budget, see what it costs to build a booking engine.
Hotel API integration FAQs
Where does a travel portal get hotel inventory from?
Is hotel booking harder to integrate than flights?
What is hotel mapping and why does it matter?
Why does the hotel price change between search and booking?
Can I add hotels to an existing flight booking portal?
I build and run a live travel reservation platform connected to four GDS / supplier integrations, and I've built admin platforms for enterprise teams. I write about the problems I actually solve for clients.
Adding hotels to your travel portal?
I build travel portals and booking engines, and I run a live platform that sells more than flights. Tell me which suppliers you're considering, your main destinations and how your portal is built today, and I'll help you plan the hotel integration and build it properly. See what my travel portal development service covers, or my booking engine development work.
Start a project →