DEV Community: Matan Rabi

I benchmarked seven hotel price APIs on the same Rome room, and the prices were 16% apart because of tax

Matan Rabi — Wed, 07 Oct 2026 14:52:15 +0000

I run FlightPowers, a small API that reads live Booking.com rates, so I'm biased about one row of this table. I wanted to know how it holds up next to the APIs people usually compare it with, so I spent an afternoon sending them all the same questions and kept every response.

The setup

Same stay for everyone: check-in 2026-11-20, check-out 2026-11-23, 2 adults, 1 room, USD. Three questions, three runs each, median wall time from one server in the US:

A destination search for Lisbon, sorted by price where the API can sort.
One named hotel: Hotel Artemide in Rome. (I started with Hotel Sant'Angelo, but it was sold out on Booking.com for those dates.)
That same hotel seen from Germany and from the US, where the API has an input for it.

Free tiers only. SerpApi got no_cache=true, because its default hands back an identical search from cache for an hour and that would have flattered its time.

Speed and sorting

API (source)	Lisbon search, median	sorts by price	one named hotel
StayAPI (Booking.com)	1.1 s	no	2 calls: ID lookup, then prices (2.5 s for the prices call)
SearchApi (Booking.com)	1.9 s	yes	room list in 2 calls: search for the URL, then the property (3.0 s for that call)
HasData (Booking.com)	2.1 s	yes	room list in 2 calls: search for the URL, then the place (3.2 s for that call)
SerpApi (Google Hotels)	2.4 s	yes	1 call by name (2.5 s)
FlightPowers, mine (Booking.com)	7.9 s	no	1 call by name (10.2 s)
Apify voyager/booking-scraper	75 s with actor start	asked, rows came back unsorted	1 run by name (39 s, one run)
Xotelo (TripAdvisor rates)	0.7 s, but the list takes no dates	n/a	by TripAdvisor key (0.7 s)

Mine is the slow one. It loads the page in a real browser through a residential proxy for every call, and you pay for that in seconds. It also has no price sort yet: I sent "sort": "price" and it was accepted and ignored, which is a bug on my list.

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

One room, two prices

Hotel Artemide, Basic Double, those three nights. Here is what each API called the price:

where the number came from	what came back
HasData	$914.64 + $142.12 tax = $1,056.76
StayAPI, US market	`total_price` $914.64, tax listed as not included
StayAPI, German market	`total_price` $1,061.71, tax listed as included
SearchApi	$915, no tax field on the room rows
FlightPowers, `proxy_country=us`	$1,057, three runs out of three

Same rate underneath. Booking.com shows a US visitor the room before tax and adds 10% VAT and the Rome city tax at the end. The German view folds them into the price. So the number you store depends on which field an API calls the price and which market it read from. StayAPI's total_price means before tax in one market and after tax in the other, for the same room. Its docs warn that the market changes tax display, and the tax breakdown says which way it went, so you can fix it if you read it.

If you load hotel rates into anything that compares sources or countries, normalise to the tax-inclusive total first. Otherwise a 16% "price gap" shows up that's only accounting.

Two smaller ones. The cheapest Lisbon row on SearchApi and on HasData was the same hostel bunk ($51 before tax, $81 after). And the Apify scraper's cheapest result was one bed in a 10-bed dorm priced for one person, on a search for two adults.

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. Mine, tax included both times, read $1,028 from Germany on two of three runs and $1,057 from the US on all three. Without a pinned country mine moves more ($935, $1,011 and $1,062 for the Basic Double on three calls to the room list), because each call can leave from a different country's residential IP. Pinning helps but doesn't settle it: the Germany runs still read $1,062 once and $1,028 twice.

What it costs at the entry plan

Read from each vendor's pricing page the same afternoon:

HasData: a Booking.com call is 10 credits, so about $0.003 a call on the $59 plan (200,000 credits)
SearchApi: $0.004 ($40 for 10,000), 100 free requests once
FlightPowers: $0.005 ($10 for 2,000), 10 free a month
SerpApi: $0.025, their cheapest plan is $25 for 1,000, 250 free a month
StayAPI: $0.033 ($49 for 1,500), 50 free requests once

So two of them are cheaper per call than mine. What mine has is the $10 entry and one tax-inclusive total from a country you pick.

Caveats

One afternoon, one server, three runs a query. Google Hotels is a metasearch across sellers (34 of them for Artemide), so SerpApi's Lisbon list isn't the same set of hotels as the Booking.com APIs. Makcorps isn't in the timings because its sign-up wanted a username and password and I stuck to Google sign-ins, and the Booking.com Demand API needs a partner contract.

The full write-up, with every price source and the per-call timings, is on the benchmark page. I'll rerun it next month. If you store hotel prices somewhere, I'm curious whether you keep the before-tax number with tax in its own column, or the total.

I benchmarked four Google Flights APIs on the same searches, and the fares matched to the dollar

Matan Rabi — Wed, 07 Oct 2026 14:50:55 +0000

I sell a Google Flights API (FlightPowers), and I wanted a real answer to how it compares to SerpApi, SearchApi and HasData. So I ran the same three searches through all four in the same hour on 7 October 2026 and timed every call.

Disclosure up front: I built one of the four rows. The method, the places where mine loses and the timing of every single call are public on the benchmark page, and I'll re-run it every month.

The searches

A round trip, JFK to LHR, out 18 November, back 25 November.
A one way, TLV to BKK on 3 December.
A flexible scan, LHR to BCN, any departure from 10 to 16 November, 3 nights (seven date pairs).

One adult, economy, USD, three runs per search per API, from a VM in GCP us-central1. The time quoted is the median of the three runs, from sending the request to reading the last byte.

The results

	FlightPowers (mine)	SerpApi	SearchApi	HasData
Cheapest fare, all three searches	same	same	same	same
Round trip, both legs	3.27 s, 1 request	6.36 s, 2 requests	4.29 s, 2 requests	7.56 s, 2 requests
First round-trip price	3.27 s	2.26 s	1.98 s	5.23 s
One way	1.56 s	1.34 s	1.50 s	2.79 s
7-date scan, 7 calls in parallel	3.11 s	4.54 s	28.37 s*	15.99 s*
Whole range in one call	MCP server, bills 7	no	calendar engine, bills 1	no
Price history series	no	yes	yes	yes
Free tier	10 a month	250 a month	100, once	67 a month
Entry plan	$10 for 2,500	$25 for 1,000	$40 for 10,000	$59 for 13,333
Per 1,000 round trips with both legs	$4.00	$50.00	$8.00	$8.85

* One call took 16 to 28 seconds in two of the three runs (the median call was 1.9 s on SearchApi and 3.0 s on HasData, which ran 5 at a time on its trial account). A parallel scan waits for its slowest call.

The fares were identical

All four returned $692 for the round trip, $619 for the one way and the same lowest price on each of the seven scan dates ($93 at the bottom, leaving Saturday 14 November), with the same Google price range. The only difference was a label: SearchApi called two of the seven scan dates "high" where the other three said "typical". That makes sense, since all four read the same Google Flights results, but it means nobody should pick one of these on "better prices".

The round trip is where they differ

SerpApi, SearchApi and HasData answer a round trip with the outbound options, each priced as a round-trip total. The return flight is a second request with a departure_token, and all three say so in their docs (quoted on the page). Mine pairs both legs in one request, which is why "both legs" is one request and 3.27 s here, and why a round trip with its return flight works out at $4.00 per 1,000 against $8.00 to $50.00.

curl -X POST https://api.flightpowers.com/v1/flights/roundtrip \
  -H "x-api-key: $FLIGHTPOWERS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"from_airport":"JFK","to_airport":"LHR","departure_date":"2026-11-18","return_date":"2026-11-25","currency":"USD"}'

Where mine loses

The first price. SearchApi and SerpApi put a round-trip total on the table faster (1.98 s and 2.26 s against my 3.27 s). If you never need the return flight's details, they're quicker.
Every itinerary. With limit: 100 my round trip took 15.68 s, since each extra outbound needs its own return-leg page.
The free tier. Ten requests a month on the key. The bigger free path is the ad-supported MCP server (50 searches a day with a Google sign-in), which only helps if you use an MCP client.
Price history. The other three return a price_history series, and I return Google's band and its low, typical or high verdict only.
Date grids. SearchApi's calendar engine prices every date pair for one billed search. My one-call scan bills one request per date pair.
Billing. The other three count successful searches only. On RapidAPI every request that reaches my listing counts, one I reject as invalid included.

APIs I couldn't run

FlightAPI.io and Duffel only offer password sign-ups (I only used Google sign-ins for this), Duffel is a booking API with test data anyway, Amadeus Self-Service closed in July 2026, and Kiwi Tequila, Skyscanner and Travelpayouts need an application, an invitation or a traffic minimum. Sources for each are on the benchmark page.

If you've used any of these in production, I'd like to know which number actually made you pick one. The full table, the method and the per-call JSON are on the page :)