Booking.com API: Search Is Not the Reservation

A Booking.com API is a partner Demand API. It can show stays. It can send the traveller to Booking.com to finish. It can, with approval, create the order in your app. People type the query when they only wanted JSON for a city and dates.

This page draws that line. Ktemia is compare, including hotel search AI. We are not Booking.com. We do not hand out Demand keys. Routes are not live. No invented room rates.

Key Takeaways

• Booking.com Demand API: content, search-look-redirect, or search-look-book (book needs approval).
• Expedia Rapid is a different partner booking path: shop, price check, then book.
• Search is comparison. A confirmation is an order.

What is the Booking.com Demand API?

Booking.com’s About the Demand API (docs retrieved 20 September 2026) says the Demand API gives your application access to Booking.com travel services, including accommodation, car rentals, and attractions.

You can display content, let travellers search and compare, redirect them to Booking.com, or build an integrated order experience. Five flows: content only; search, look and redirect; search, look and book; post-booking management; reporting and reconciliation.

Accommodations collection: content, search, availability, order, post-booking. Cars: similar, with search-look-and-book in beta on that page. Attractions: content and redirect (beta), not a full book row in that table.

The head term booking.com api sounds like a search SDK. The overview is a distribution contract. If you only needed properties for a city and nights, you are looking at one slice of a stack that also wants orders, notifications, and reconciliation. Wiring /orders/create because a tutorial was titled “search” is how you become an OTA by accident.

Their accommodations search docs are explicit: the Demand API is not a full mirror of Booking.com’s consumer front end. Partners should not compare API prices one-to-one with the website. Coverage is the integrator product, not the consumer app cloned.

Search, look, redirect vs search, look, book

Search, look and redirect: the traveller searches on you, sees details, then follows Booking.com’s url or deep_link_url (with your affiliate id) to complete the stay on Booking.com. You did not take the payment. You still used their search.

Search, look and book: you call orders preview and create, guests and pay in your app. Booking.com’s accommodation tutorial says that flow needs partner approval, a business case, and an appropriate agreement.

A citation you can lift: Demand API search can feed a redirect or, if you are approved, an in-app reservation. The search step is not the reservation. Ktemia stops at compare. We do not run Demand orders/create.

Required on a stay search here: city and dates. Copilot asks if either is missing. It does not invent Lisbon because you said “weekend.” Worked flight query on this site stays LIS → LHR, 2026-10-12; a stay still needs nights in the city you actually want. We will not paste a fake hotel JSON.

How is Expedia API different?

People bundle expedia api with booking.com api because both are OTA partner platforms. They are not one key.

Expedia Rapid is positioned as a lodging path from shopping to booking to payment. Sign-up FAQ: you need to become a partner. Developer Hub lodging docs: shop with dates, occupancy, property IDs; price check; then booking with guest and payment. Flight Rapid adds shopping, details, payment token, create booking, retrieve itinerary.

Rapid’s marketing numbers (inventory, call volume) live on that partner page. We are not those numbers. We are not Rapid. Mentioning Rapid is so you do not treat “Expedia API” as a public hotel search dump.

Same lesson as Demand: shop is the compare-looking step on a book path. If you never take payment, you wanted search, not Rapid Booking Create.

GDS vs booking engine vs a search API is the generic vocabulary. Demand and Rapid are two branded booking engines with a shop door.

What Ktemia is, on stays

Terms: search and compare flights, stays, cars, and homes. Results from third parties. Prices can change. A search is not a reservation unless a separate booking flow says so. This post is not that flow.

Product is UI, APIs, copilot on one compare job. Free includes UI search for stays and 50 API requests a month when routes exist. Do not put a dashboard key in frontend JavaScript. Do not paste a Booking.com partner secret into a browser either.

If your tab is Demand API orders, you are building an OTA on Booking.com’s paper. If your tab is Rapid Booking, you are building on Expedia’s. If your tab is city + dates and a rankable list, you are in search. Ktemia’s hotel URL is the third tab. Do not retitle it Booking.com API.

Flights comparisons (Amadeus, Skyscanner, Tequila, Google Flights) are other posts. Stays do not steal those keywords. Search a trip or a move is the package when a stay sits next to a fare, a car, and a listing.

Search the stay. Do not borrow an OTA’s checkout.

Booking.com API, in official docs, is Demand: search plus a fork toward redirect or book. Expedia API, in Rapid docs, is a booking path with a shop step. Ktemia is compare.

Caps: pricing. Platform: search a trip or a move. Flights HTTP: flight search API. Demand API against the rest of the field: best travel API. Routes are not live. When they are, this URL still will not become a Demand tutorial.