Hotel API overview
You use one API to find, book and cancel a multiroom stay.
In short
1 callFor people and agentsThe same list heads this page's Markdown:/hotel/hotel-overview.md
You use one booking flow for a stay with one or more rooms: search, price selected hotels, prebook with guests, then pay and book. Your hotel IDs belong to this service, and your offer reference binds the supplier internally.
Choose your next step
- Start with Hotel getting started for a two-room request sequence.
- Follow the gateway authentication guide to configure your server-side API key.
- Use Hotel booking flow for guest assignment and payment choices.
- Use Hotel booking lifecycle and Hotel retries and idempotency to decide what to do after each response.
- Read Hotel cancellations and recovery before requesting release or displaying a refund.
Keep the complete stay together
You price the whole party, with one occupancy per room and every child's age. Each offer covers that room combination for the complete stay. You cannot combine room selections from separate offer references.
You select one supplier per search. Your offers request uses hotel IDs from one supplier, and the chosen offer keeps prebook and booking with that supplier. A hotel ID identifies a listing; you must not assume two suppliers' listings for the same property share an ID.
You read GET /v1/hotel/capabilities before preparing supplier-specific requests. It lists active, configured suppliers with the operations and limits this service supports: rooms per stay, maximum child age and hotels per offers request. You still follow the common request limits, including hotel count times max_offers_per_hotel of at most 250. The list is shared across organizations; it does not select your supplier, describe your routing rules or guarantee inventory. Your search response's meta.supplier identifies the supplier selected for that search.
You can receive a response such as the following when LiteAPI is the only active, configured supplier. Your actual list can differ.
{
"data": [
{
"supplier": "LITEAPI",
"operations": [
"search",
"offers",
"content",
"price_calendar",
"prebook",
"book",
"cancel"
],
"limits": {
"max_offer_hotels": 10,
"max_rooms": 8,
"max_child_age": 17
},
"requires_named_adults": false,
"cancellation_may_partially_succeed": false
}
]
}You name every adult and specify each guest's type when requires_named_adults is true; all bookings require a named adult lead for every room. When cancellation_may_partially_succeed is true, your cancellation can leave a mixture of canceled and confirmed rooms. Your public cancellation request always covers the whole booking, so this flag does not let you choose individual rooms. Read the booking and its room outcomes after a cancellation.
You treat operations as supplier-backed hotel features, not a list of every endpoint. Place lookup and booking weather use shared service integrations; their availability is independent of the booked hotel's supplier. A missing price_calendar operation means you cannot request that supplier's hotel listings through the price-calendar endpoint. An empty capability list means no active, configured supplier is registered; a failed read returns an error instead. Recheck capabilities when a supplier becomes unavailable, because configuration and supplier status can change.
You read descriptions, images, facilities and reviews through the content endpoint. Content does not reserve inventory or guarantee the price of a stay.