How hotel supplier APIs work for online travel agencies

Hotel supplier APIs give online travel agencies access to hotel rooms in two parts: static content, such as hotel names, photos and facilities, which changes rarely, and live availability and rates, which change constantly. On top of that sit rate conditions, board types and cancellation policies that vary from one rate to the next. Understanding these layers explains why hotel search and booking are harder to build than they first appear.

An API (application programming interface) is a structured way for two systems to exchange data. A hotel supplier API lets your booking platform ask a supplier which rooms are available and at what price, and then book them. This guide explains how that data is organised and what slows hotel search down. If you are planning a hotel booking platform, our OTA platform service page explains how we build them.

Static content and live availability are separate

Most hotel supplier APIs split their data into two kinds.

Static content

Static content describes the hotel itself and changes infrequently:

• Hotel name, address and coordinates.
• Star rating, descriptions and facilities.
• Photos.
• Room type descriptions.
• Policies such as check-in times.

Suppliers usually provide static content through a separate download or content API. Your platform imports it, stores it in its own database and refreshes it regularly. Storing it locally means your hotel pages load quickly and do not depend on the supplier for every visit.

Live availability and rates

Availability and rates change with every booking and every pricing update, so they are requested live:

• Which room types are available for the chosen dates and guests.
• The price for each rate, with taxes and fees.
• The conditions attached to each rate.

Your platform sends a request with the destination or hotel IDs, dates and guest details, and the supplier returns the current options. Because these requests are slower and more expensive than reading static content, a well-built platform keeps them focused and caches the results briefly.

A worked example

A customer searches for a double room in one city for three nights.

1. Your platform looks up the hotels in that city from its own stored static content and prepares their supplier IDs.
2. It sends one live availability request to the supplier with those IDs, the dates and two adult guests.
3. The supplier returns only the hotels with available rooms, each with its rates and prices.
4. Your platform combines the live rates with the stored names, photos and facilities, and shows the results.

The photos and descriptions never travel in the live request. That keeps the search smaller and faster, and the hotel pages still load even if the supplier is slow.

How room rates and board types are returned

A single hotel can return many options for the same dates. Each option usually combines:

1. A room type, such as a double room or a family room.
2. A board type, which describes meals included, such as room only, breakfast included, half board or all inclusive.
3. A rate type, such as a flexible refundable rate or a cheaper non-refundable one.
4. The price, often with taxes and fees shown separately, and sometimes with charges payable at the hotel.
5. An identifier your platform must keep and send back when checking the price and booking.

Suppliers describe rooms and boards in their own words, and the same room can appear under slightly different names from different suppliers. Your platform should convert each supplier's format into a consistent structure, so customers see clear, comparable options and your team can manage them in one admin panel.

Cancellation policies and why they vary by rate

Two rates for the same room on the same night can have very different cancellation terms.

• Refundable rates allow free cancellation until a deadline, after which a fee applies.
• Non-refundable rates are cheaper but cannot be cancelled for a refund.
• Partial policies charge a fee that increases closer to the arrival date.

Policies vary because hotels and suppliers price flexibility differently. A cheaper rate often means less flexibility. For customers, the cancellation policy can matter as much as the price, so it should be clear before they choose a rate.

For example, the same double room with breakfast might come back as two rates: one refundable until a set date before arrival, and a cheaper one that is non-refundable. Showing them side by side with plain labels, such as "Free cancellation until [date]" and "Non-refundable", lets the customer choose knowingly. Showing only the cheaper price, with the policy hidden in small print, leads to complaints and refund disputes later.

Cancellation details can also change between search and booking. That is one reason suppliers usually require a price check, often called prebook, just before the final booking. It confirms the current price and the policy that will apply. Our guide to the hotel prebook step explains how to handle changes at that stage.

Store the policy exactly as confirmed at booking time, so refunds and support later follow what the customer agreed to.

Hotel mapping across different suppliers

Many agencies connect to more than one hotel supplier for wider coverage and better rates. Each supplier has its own hotel list and its own hotel IDs, so the same building appears several times under different identifiers.

Hotel mapping means matching these records to one hotel in your own master list:

1. Create your own hotel IDs and link each supplier's IDs to them.
2. Match automatically using coordinates, cleaned-up names and addresses.
3. Review uncertain matches by hand, such as hotels in the same building or hotels that changed names.
4. Keep mapping up to date as suppliers add and change hotels.

Without mapping, customers see duplicate hotels with different prices, which is confusing and looks unprofessional. Our guide on connecting multiple hotel suppliers to one booking engine explains mapping and rate merging step by step.

Choosing which kinds of source to connect is a separate decision, and our comparison of hotel aggregator APIs and direct contracts covers the trade-offs.

What slows hotel search down

Hotel search can feel slow for several reasons, most of which can be reduced with good design.

1. Large searches. A search for a whole city can involve many hotels and many rates each. Returning and processing all of them takes time.
2. Several suppliers. Asking suppliers one after another adds their response times together. Asking them at the same time, with a time limit for each, is much faster.
3. Slow supplier responses. Some suppliers respond more slowly at busy times. Your platform should show results from those that answered rather than waiting indefinitely.
4. Converting data. Normalising each supplier's rooms, boards and prices takes processing time, especially for large responses.
5. Too many repeat requests. Filtering or sorting should use stored results rather than new supplier requests.
6. Search limits. Suppliers often limit how many searches you can make compared with bookings. Unnecessary searches waste that allowance.

Practical ways to speed it up

• Store static content locally and only request live rates.
• Search suppliers in parallel with per-supplier timeouts.
• Cache search results for a short time for filters and paging.
• Show results progressively, or show a clear loading state, rather than a blank page.
• Log response times per supplier to spot problems early.

For the flight side of travel APIs, see our guide to what a flight booking API is and how travel agencies use it.

The same integration habits, such as logging every request and setting time limits, are covered step by step in our guide on how to integrate a flight API.

Summary

• Hotel supplier APIs separate static content, stored locally, from live availability and rates, requested at search time.
• Each option combines a room type, board type, rate type, price and an identifier needed for booking.
• Cancellation policies vary by rate and can change before booking, so confirm and store them at prebook.
• Hotel mapping links each supplier's hotel IDs to your own master list and prevents duplicates.
• Parallel searches, short caching and local static content keep hotel search fast.

Understanding how hotel data is structured makes it much easier to plan a reliable booking platform. If you're planning to connect hotel suppliers to your website, you can tell us about it here.