Table of Contents
Two aggregators quote you “per API call.” One looks half the price. You sign it — and your bill comes in higher. The headline rate told you almost nothing. Here is how hotel API aggregator pricing actually works, and the questions that decide what you really pay.
Here’s a scene that plays out constantly. An OTA is choosing a hotel API aggregator. Two vendors send quotes. One is priced “per API call” at what looks like half the rate of the other. The cheaper one wins, the contract gets signed — and three months later the bill arrives noticeably higher than the “expensive” option would have been. Nobody lied. The headline rate simply never told the whole story.
This is the thing about hotel API aggregator pricing: the number on the rate card is the least useful piece of information in the whole decision. What you actually pay is decided by things that don’t appear on the card at all — how many searches it takes to make a booking, how the rates themselves are marked up, and whether you’re being charged in one place or two.
This guide pulls those hidden mechanics into the open. With the bedbank market projected to reach $118.7 billion by 2034 and aggregators sitting between OTAs and that supply, understanding how they price isn’t optional — it’s the difference between a margin that holds and one that quietly erodes on every booking.
Almost every aggregator uses one of these four models — or, more often, a combination. Knowing which you’re being quoted is step one; understanding what each does to your bill is step two.
You pay per request — typically per search and/or per booking call. Fair in principle: you pay for what you use. The catch is that “a request” is elastic. One hotel search on your site can trigger many calls behind the scenes, and heavy searching with light booking inflates the bill fast.
You pay only on confirmed bookings — a percentage or a flat amount. Predictable per transaction and friendly when you’re starting out, but the cost rises in lockstep with your success, the same margin dynamic we cover in our booking engine pricing guide.
A flat platform fee, sometimes with a usage allowance and overage charges above it. Predictable and easy to budget, but you can overpay at low volume or hit overage walls as you grow.
Some aggregators charge little or no obvious fee — because their margin is baked into the rates they pass you. You receive a net rate that’s quietly marked up from the true net rate. There’s no line item; the cost is the spread. This is the layer that makes a “cheap” headline expensive, and we’ll come back to it.
Here’s the mental model that makes aggregator pricing legible. Every quote has three layers, but vendors only show you the first. The other two — the ones that actually move your bill — you have to dig for.
“The Three Hidden Layers of Aggregator Pricing” — a ZentrumHub framework for reading a quote.
Layer 2 is where most pricing surprises come from, and it has a name every OTA should know: the look-to-book ratio — the number of searches it takes to produce one confirmed booking. In hotel retail, that ratio is rarely small; it can be hundreds of searches per booking, depending on your traffic, your conversion, and how your search behaves.
Now layer that onto per-call pricing. If you’re charged per search and your look-to-book ratio is high, the cost of each booking is the per-search rate multiplied by all those non-converting searches. A vendor with a lower per-call rate but a model that encourages more calls can easily cost you more per booking than a “pricier” vendor whose efficiency is better. The rate card said one thing; your invoice says another.
Two technical factors swing this hard. Caching — whether repeated or recent searches are served from cache rather than re-billed — can change your call volume dramatically. And search efficiency — how many supplier calls the aggregator makes per user search — determines how your front-end activity translates into billed events. Neither appears on a rate card, and both matter more than the rate.
“At my look-to-book ratio and search volume, what is my expected cost per booking — not per call?” A vendor who can answer this clearly is pricing you honestly. A vendor who only repeats the per-call rate is leaving the expensive part for you to discover later.
Layer 3 is the one that catches even experienced buyers, because it isn’t a fee — it’s a price. When an aggregator passes you a net rate, that rate can already include a margin over the true net rate the supplier gave. You don’t see a line item. You just receive a slightly higher cost of goods on every room you sell, forever.
This is why a “no platform fee” or rock-bottom per-call quote can be the most expensive option on the table. If the headline is cheap because the margin moved into the rate spread, you’ll pay it on every booking — and unlike a usage fee, it scales directly with your sales volume. The cheaper the sticker looks, the more worth checking where the margin actually went.
None of this means rate margin is wrong — aggregators provide real value and have to earn from somewhere. The point is transparency. You want to know which layer your cost sits in, so you can compare two vendors on the same basis instead of comparing one vendor’s visible fee against another’s invisible spread.
Ask each vendor to express their total economics — usage/platform fee plus any rate margin — as one combined cost per booking at your real volume and look-to-book ratio. Whoever can do that is showing you all three layers. Whoever can’t is showing you one.
Collapse all three layers and you get the one figure that actually compares vendors: your fully-loaded cost per booking. It’s the headline rate, run through your real look-to-book ratio and search efficiency, plus any rate spread — divided by the bookings you actually make.
When you evaluate aggregators on fully-loaded cost per booking, the rankings often flip. The “cheapest per call” vendor can land last; the one with a slightly higher headline but better caching, search efficiency, and transparent rates can be meaningfully cheaper where it counts. Everything else — the per-call rate, the subscription tier, the commission percentage — is just an input to this one number.
Stop asking “how much per call?” Start asking “what’s my fully-loaded cost per booking at my volume?” The first question is the one vendors want you to ask. The second is the one that protects your margin.
This is the logic behind ZentrumHub’s pricing: pay-as-you-go based on actual API traffic, so your cost tracks your real usage rather than a tier you’ve outgrown or under-filled — paired with sub-500ms responses and deduplication that keep your call volume efficient in the first place. The aim is to keep all three layers visible, so you can see your fully-loaded cost per booking instead of discovering it on an invoice. You can see how this connects to the wider provider landscape in our hotel API providers comparison.
ZentrumHub prices on real API traffic — usage-based, with deduplication and sub-500ms responses keeping your call volume efficient. See your fully-loaded cost, not a headline rate.
See the Universal Hotel API →Take these into any aggregator pricing conversation. Each one pulls a hidden layer into the light:
ZentrumHub charges pay-as-you-go on real API traffic — with deduplication and sub-500ms responses keeping your call volume efficient, and one connection to 100+ suppliers. No tier you’ve outgrown, no surprise on the invoice. 30M+ daily API calls. 99.99% uptime.
Drop your work email and we’ll send you the 12-page report that breaks down where 6–9 months and $215K+ quietly disappear — free.
