Hotel rates API benchmark 2026: seven APIs, one hotel, real calls

Published October 7, 2026

Short answer: I sent the same Lisbon search and the same Rome hotel to seven hotel price APIs on 2026-10-07, three runs each. StayAPI, SearchApi and HasData answered a Booking.com destination search in 1.1 to 2.1 seconds and SerpApi's Google Hotels engine in 2.4. Mine, FlightPowers, took 7.9, slower than every API here except an Apify scraper run, which took 75. The bigger finding was the price: the same room came back as $915 or as $1,057 depending on whether the API put Rome's VAT and city tax into the number it called the price.

I run FlightPowers and sell one of the APIs in this test, so read my rows as a vendor measuring himself. Every number below is from a call I made that afternoon, with the raw response kept, and the list of where mine loses is longer than the list of where it wins.

How I tested

Same questions, same dates, every API: check-in 2026-11-20, check-out 2026-11-23 (3 nights), 2 adults, 1 room, prices in USD.

1. Destination search: Lisbon, sorted by price wherever the API can sort.
2. One named hotel: Hotel Artemide, Rome. I meant to use Hotel Sant'Angelo, but it was sold out on Booking.com for those dates, so everyone got Artemide.
3. The same hotel seen from two countries, Germany and the US, wherever the API has an input for it.

Wall time is from the request leaving to the last byte of the answer, from one server in the US, three runs per question, median shown. SerpApi got no_cache=true, because by default it serves an identical search from its cache for an hour and that would flatter the time. All calls ran between 14:00 and 14:17 UTC on free tiers. Makcorps is not in the timings: its sign-up wants a username and password, and I only signed up where Google sign-in was offered. The Booking.com Demand API is not in them either, because it needs a partner contract.

Every call's start time, wall time and status is in the per-call timings file, 63 calls in all.

Speed and results

The two cheapest Booking.com rows in Lisbon were the same dorm bunk at Samps Hostel on SearchApi and HasData, $51 before tax and $81 after. SerpApi reads Google Hotels, which is a metasearch across many sellers, so its Lisbon list is a different set of hotels and not a like-for-like row.

SearchApi's and HasData's search also take a hotel name (SearchApi put Hotel Sant'Angelo first when I searched it by name), so a single row price for a named hotel is one call there too; the second call in the table is for the full room list.

One room, three prices

Hotel Artemide, Basic Double Room, 20 to 23 November 2026, 2 adults:

Almost all of the spread between $915 and $1,062 is tax display, not a different rate. Booking.com's US view shows the room before tax and adds VAT and city tax at the end; the German view folds them in. So StayAPI's total_price means "before tax" in one market and "after tax" in the other for the same room. Their docs warn that the market can change tax inclusion, and the tax breakdown says which way it went, so a careful client can fix it, but a dashboard that compares the field across markets will invent a 16% gap that isn't there.

If you are comparing hotel APIs, or comparing countries, compare the tax-inclusive total.

Does the country change the rate?

A little, on this hotel. StayAPI's before-tax figure was $919.14 from Germany and $914.64 from the US, 0.5% apart. Mine, with the tax folded in on both, read $1,028 from Germany on two of three runs and $1,057 from the US on three of three, under 3% apart. That matches what I found when I sampled three hotels from several countries in August: gaps are real but modest, they depend on the property, and one reading per country measures the noise as much as the market (the sampled version).

Which APIs let you ask: mine (proxy_country, a residential exit in that country), StayAPI (country_market, which their docs call "a request value, not verified geography") and SerpApi on Google Hotels (gl). The Booking.com engines at SearchApi and HasData had no country input; both sell a Google Hotels engine with gl separately.

What it costs

Read from each vendor's own pricing page at 14:09 UTC on 2026-10-07.

Units differ. A search request on SearchApi, HasData, StayAPI or mine returns a page of hotels; an Apify charge is per hotel row; StayAPI's ID lookup and the URL searches before a named-hotel call are requests of their own.

Where mine loses

1. Speed. 7.9 s on the search and 10.2 s on a named hotel, against 1.1 to 3.2 s for the four other APIs. Each call loads Booking.com through a residential proxy in a real browser, and that is the cost of it.
2. No price sort. Results come in Booking's popularity order. Worse, I sent "sort": "price" and the API took it without an error and ignored it. That one is a bug, and it's on my list.
3. Row count moves. 15, 25 and 15 rows on three identical calls. HasData and StayAPI returned 25 every time and both page.
4. No tax breakdown. You get one tax-inclusive total. HasData and StayAPI itemise VAT and city tax, which a parity tool needs.
5. A named hotel returns one room. The full room list is a second endpoint (/v1/hotels/rooms, 8.9 s), and in one of three default runs the by-name call returned a different room than the other two.
6. The number moves between calls. Without proxy_country, each call can leave from a different country's residential IP: the Basic Double read $935, $1,011 and $1,062 on three calls to the room list. Pinning a country helps but doesn't settle it: proxy_country=us read $1,057 three times out of three, proxy_country=de read $1,062, $1,028 and $1,028.
7. Per request, two are cheaper. HasData and SearchApi cost less per call at their entry plans. What mine has is the smaller ticket: $10 to start, against $40, $49 and $59.
8. One source. Mine reads Booking.com only. SerpApi returned 34 sellers for Artemide in one call.

Which one I'd pick, by job

• Fast Booking.com search at volume: SearchApi or HasData. Both sort, both show the tax on the search rows, both are cheaper per call than mine.
• One hotel across many sellers: SerpApi's Google Hotels engine.
• Reviews, photos and property details on top of rates: StayAPI.
• A hotel by the name a person types, one tax-inclusive total, from a country you choose, for $10: mine. It's also on the same key as live Google Flights fares, if you need both.
• Free and good enough for a hobby script: Xotelo's rates endpoint, if you can get the TripAdvisor key.
• Selling the room: the Booking.com Demand API, through a partner contract.

Questions

What is the best hotel price API?

It depends on the job. On these calls: StayAPI was the fastest Booking.com search (1.1 s), SerpApi covered the most sellers (34 for one hotel), HasData and SearchApi were the cheapest per request at entry, and mine had the smallest monthly plan in this test, one tax-inclusive total and a country input, while being slower than every API here except the Apify scraper run, at 7.9 s.

Which Booking.com rates API includes taxes in the price?

HasData returns the before-tax price, the tax lines and a total. StayAPI's total_price includes tax in some markets and not in others, with a breakdown that says which. Mine returns one tax-inclusive total. SearchApi's property rooms came back with no tax field.

How fast is a Booking.com rates API?

1.1 to 3.2 seconds for the fastest four on a search or a named hotel, 7.9 to 10.2 for mine, 39 to 75 for an Apify scraper run.

Is there an official Booking.com rates API?

The Demand API, for Managed Affiliate Partners under contract. More on that in how to get Booking.com API access.

How much does a Booking.com rates API cost per request?

About $0.003 (HasData), $0.004 (SearchApi), $0.005 (mine), $0.033 (StayAPI) and $0.035 (Makcorps) at each entry plan, read on 2026-10-07.

Related

• The best hotel data APIs in 2026: twelve providers, prices quoted and dated
• Booking.com API alternative: live rates without a partner contract
• Do hotel prices change by country?: the sampled version of the country test
• Hotels API reference: every endpoint, with captured responses