Table of Contents
A bedbank and a hotel API aggregator get pitched as if they compete. They don’t — they sit at different layers of the same supply chain. Confusing them is how OTAs sign one integration when they needed the other. Here is the difference, in one clean test.
Ask five people in travel tech to define “bedbank” and “aggregator” and you will get versions that overlap, contradict, and occasionally swap. The confusion is not academic — it decides what an OTA integrates. A team that thinks a big bedbank is an aggregator signs one contract, celebrates the wide inventory, and rediscovers six months later that it is still a single supplier with a single point of failure and no path to the suppliers it does not carry.
This guide draws the line precisely: what each one is, a one-question test that classifies any vendor correctly, and the honest reason the two get muddled — some bedbanks genuinely aggregate now. The bedbank segment alone was worth $62.4B in 2025 and is heading to $118.7B by 2034 (Marketintelo), so getting the category right before you architect around it is worth the ten minutes.
A bedbank is a wholesale hotel supplier that contracts rooms directly from hotels at net rates and distributes them to travel sellers through its own API. It is, in one phrase, an inventory source: it owns commercial relationships with the hotels, holds allocation and net pricing, and sells that inventory to OTAs, agencies and consolidators who add their markup. When you integrate a bedbank, you integrate one supplier — its coverage, its formats, its rules, its uptime. Add a second bedbank for more inventory and you integrate a second, entirely separate supplier. This is the core economic fact of the bedbank layer: inventory scales by adding suppliers, and every supplier is another integration to build and maintain.
A hotel API aggregator is not an inventory source — it is the connection layer that unifies many inventory sources behind one API. Bedbanks, GDS platforms, OTA-wholesale programmes and direct contracts all plug into it; the aggregator fans a single search out across them in parallel, then deduplicates the same property across sources, normalises every format into one schema, and returns a clean response. You integrate once and reach everything connected. Where a bedbank answers “which hotels do I sell,” an aggregator answers “how do I connect to every supplier that sells hotels without building ten integrations.” The two operate at different layers, which is exactly why they are not alternatives.
Whenever a vendor’s category is unclear, one question resolves it: does this company hold its own contracts with hotels, or does it connect me to other companies that do? Everything else follows.
The Layer Test. The answer classifies any vendor — and exposes the ones that are quietly both.
| Dimension | Bedbank (supplier) | Hotel API aggregator (connection layer) |
|---|---|---|
| What it is | An inventory source | A way to connect to many inventory sources |
| Hotel contracts | Holds its own, directly with hotels | Holds none — connects to those who do |
| Integrations to reach 5 sources | Five separate builds | One |
| Deduplication across sources | Not its job — one feed only | Core function across all sources |
| Single point of failure | Yes — its outage is your outage | No — routes around a failing supplier |
| Maintenance | You maintain each bedbank integration | Aggregator absorbs every supplier change |
| Example | Hotelbeds (direct bedbank) | ZentrumHub (100+ suppliers, one API) |
Here is the honest complication the tidy definitions skip. Some large bedbanks stopped contracting only their own hotels and started aggregating other suppliers internally — reselling a combined pool under their own brand. RateHawk is the clearest case: it grew to 2.5M+ properties in under six years not by signing every hotel directly but by aggregating 200+ existing sources, which means an OTA integrating RateHawk alone inherits inventory from dozens of underlying suppliers through one connection. That is genuinely aggregator-like behaviour, and it is why the category feels slippery.
But the Layer Test still holds. A mini-aggregator is one commercial contract, one integration, and one point of failure — its internal aggregation is invisible to you and outside your control. If its API goes down, all of that inventory goes with it, and it cannot connect you to the suppliers it has not itself signed. A demand-side aggregator sits one level above: it can carry a mini-aggregator like RateHawk and Hotelbeds and a GDS and your direct contracts, deduplicate across all of them, and route around any one that fails. The mini-aggregator widens a single feed; the aggregator unifies every feed. The full RateHawk picture, including how its internal aggregation model works, is in the RateHawk hotel API guide.
Also Read: Hotel API vs GDS vs Bedbank: how the three inventory models compare →
The question is framed wrong the moment it becomes “either/or.” You need bedbanks — they are where a large share of bookable inventory lives, and 40%+ of global hotel bookings already flow through OTAs (Phocuswright, 2024) that run on exactly this supply. And you need an aggregator — because competitive OTAs run several suppliers at once, and connecting them one integration at a time is where teams lose quarters. The right architecture is both: choose your bedbanks for the inventory they carry in your markets, and choose a demand-side aggregator for how you connect to all of them without ten separate builds and ten separate maintenance burdens. How many sources you actually need before this matters is covered in how many hotel suppliers an OTA actually needs.
Zentrum Connect carries Hotelbeds, RateHawk, WebBeds, TBO and 95+ more in one deduplicated feed.
Explore Zentrum Connect →ZentrumHub is the aggregator layer, not a bedbank — and that distinction is the point. It does not contract hotels or hold its own inventory; it connects your platform to 100+ suppliers, bedbanks very much included, through one API. You bring your own supplier contracts and rates; ZentrumHub runs the technology on top: parallel search across every connected source, deduplication of the same property across bedbanks, one normalised schema, best-rate selection and automatic failover when a supplier stumbles. The result is 900,000+ deduplicated hotels across 190+ countries at sub-500ms, with ZentrumHub absorbing every supplier API change so your team never maintains a bedbank integration again. Bedbanks give you inventory; ZentrumHub gives you all of them at once, without the ten builds.
Also Read: Best Hotel API Aggregators in 2026: the ranked comparison by layer →
100+ suppliers, 900,000+ deduplicated hotels, sub-500ms, zero per-booking fees — live in 15 days on your own contracts.
A bedbank is a single wholesale supplier that contracts hotels directly and sells net rates through its own API — it is an inventory source. A hotel API aggregator is the connection layer that unifies many suppliers, bedbanks included, behind one API, deduplicating and normalising across them. A bedbank is one of the things an aggregator aggregates, so they are not competitors: most OTAs use bedbanks through an aggregator rather than choosing between them.
Traditionally no — a bedbank contracts its own hotels and sells one feed. But some large bedbanks now aggregate other suppliers internally and resell a combined pool, which makes them “mini-aggregators.” RateHawk is the clearest example, aggregating 200+ sources into one feed. It behaves like an aggregator in breadth, but it remains one contract, one integration and one point of failure — unlike a demand-side aggregator that carries multiple bedbanks and routes around any one that fails.
In practice, yes. You need bedbanks because they hold a large share of bookable inventory, and you need an aggregator because connecting several suppliers one integration at a time is slow and expensive to maintain. The efficient architecture is to choose your bedbanks for the inventory they carry in your markets, then connect to all of them — plus GDS, wholesale and direct contracts — through a single aggregator that deduplicates and maintains the connections for you.
Hotelbeds is a direct bedbank — it contracts hotels directly and distributes that inventory at wholesale net rates through its own API, with particular strength in European and Mediterranean markets. Apply the Layer Test: it holds its own hotel contracts, so it is a supplier, not a connection layer. It is one of the suppliers a demand-side aggregator like ZentrumHub connects to, alongside other bedbanks, GDS platforms and wholesale sources.
They price different things, so a direct comparison misleads. A bedbank sells inventory at net rates you mark up; an aggregator charges for connectivity — typically flat SaaS at the demand-side layer, with no per-booking fee at platforms like ZentrumHub. The real cost question is not bedbank versus aggregator but connecting to several bedbanks yourself versus through an aggregator: building and maintaining each integration runs $215K+ and 6–9 months per supplier, which is the line item an aggregator collapses.
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.
