What Is a Bedbank? How Bedbank APIs Work for Travel Agencies

A bedbank is a hotel wholesaler: it contracts rooms from hotels and resells them to travel agencies, OTAs and tour operators at confidential net rates, usually through an API, and the seller adds its own margin. Tripgic is a unified travel API that aggregates 2M+ properties from 50+ supply partners behind one integration and one JSON schema.

This guide is for travel agencies, OTAs, tour operators, TMCs and travel startups deciding where their hotel rooms will come from. It answers the three questions buyers ask most: what a bedbank is, which bedbanks sell to the trade through an API, and whether a growing OTA should sign direct contracts with bedbanks or use a hotel API aggregator. It also walks through a bedbank API booking call by call, the contract terms that decide your margin, and a worked example. You will see the word spelled two ways, “bedbank” and “bed bank”; both mean the same thing. If you want the wider market first, our guide to hotel API providers compares five types of hotel supplier side by side.

What Is a Bedbank?

A bedbank, also called a hotel wholesaler, is a business-to-business company that sells hotel rooms to the travel trade, not to travellers. It signs contracts with hotels, hotel chains and other accommodation suppliers, loads their rates and availability into its own system, and resells the rooms to travel sellers at net rates: wholesale prices with no seller margin built in.

The travel seller adds its own markup and sells the room under its own brand. The traveller books and pays the agency or OTA and usually never sees the bedbank’s name. The bedbank confirms the booking, the hotel holds the room, and the bedbank pays the hotel under its own contract.

Three features set a bedbank apart from other hotel sources:

• Trade only. It sells to businesses (OTAs, agencies, tour operators, TMCs, DMCs, airlines and other wholesalers) and asks for a business account before it shows rates.
• Net, confidential pricing. Its rates are not public prices, and contracts commonly limit how and where a net-based price may be shown.
• One contract, many hotels. The seller signs one agreement and reaches the bedbank’s whole inventory instead of negotiating hotel by hotel.

Many bedbanks also sell transfers, activities and car rental beside rooms, which is why some now describe themselves as B2B travel marketplaces rather than bedbanks.

Where a Bedbank Sits in the Hotel Supply Chain

A hotel room can pass through several hands between the property and the traveller. Seeing the whole chain makes the rest of this guide easier, because “one bedbank, many bedbanks or an aggregator” is really a question about how many links you run yourself.

Role	What it does	Who it sells to
Hotel or chain	Owns the rooms and sets rates for each channel	Direct guests, OTAs, bedbanks, tour operators
Channel manager	Pushes the hotel’s rates and availability to many channels	Works for the hotel
Bedbank / wholesaler	Holds hotel contracts and resells rooms at net rates	Travel businesses only
Hotel API aggregator	Puts many suppliers, including bedbanks, behind one API and one format	Travel businesses only
Travel seller (OTA, agency, TMC, tour operator)	Adds a margin, packages and sells under its own brand	Travellers and corporate clients
Traveller	Books and pays the seller	—

Not every booking uses every link. An agency with a direct hotel contract skips the bedbank; an OTA with one bedbank skips the aggregator. But every link you skip becomes a contract, an integration and a settlement flow that you run yourself. That trade-off between control and workload is the thread through every section below.

Where Does a Bedbank Get Its Rooms?

A bedbank’s value is its supply, and that supply comes from a mix of sources. Knowing the mix tells you how strong its rates are likely to be in a given city.

• Direct hotel contracts. The bedbank’s contracting team negotiates rates with hotels, often destination by destination. These are usually its strongest rates.
• Allotments. A block of rooms per night held for the bedbank, usually with a release period: rooms not sold by a set number of days before arrival go back to the hotel.
• Free sale or dynamic rates. The bedbank sells from the hotel’s live availability, often as a discount on a dynamic rate, with no rooms held in advance.
• Channel-manager connections. Many hotels load bedbank rates through the same channel manager that feeds their OTAs, so changes arrive automatically.
• Third-party supply. Some bedbanks resell other wholesalers’ inventory to fill gaps, which is one reason the same hotel appears through several sources.

Two things follow for a buyer. First, a headline hotel count mixes all of these, so it says little about rate quality in the cities you sell. Second, rooms sourced through another supplier may carry an extra layer of margin. Ask each bedbank which properties in your top destinations it contracts directly.

What Is a Net Rate and How Does Your Margin Work?

A net rate is the wholesale price a bedbank charges the travel seller, with no seller margin built in; the seller adds its own markup and sets the selling price. That is the commercial core of the bedbank model, and it differs from a commissionable rate, where the supplier sets the price and pays the seller a commission after the stay.

Rate type	What the seller receives	Who sets the selling price	Typical source
Net rate	A wholesale cost; the seller adds its own markup	The seller	Bedbanks, wholesalers, aggregators
Commissionable rate	A public price; the supplier pays a commission after the stay	The supplier	Hotels, chains, some OTA programmes
Public (retail) rate	Nothing built in	The hotel	Hotel website, consumer OTAs

With a net rate, the seller controls its margin. It can take a higher markup on a hard-to-find room, a lower one on a competitive city hotel, or fold the room price into a package. With a commissionable rate, the margin is fixed by the supplier and paid later, sometimes weeks after the stay.

Net rates bring one duty: display rules. Hotels agree net rates “along with rules covering markets, stay dates and cancellation terms”, as the hotel software company Mews puts it in its guide to bed banks, and it adds that parity is harder to manage in wholesale because a net rate “can be redistributed multiple times”. In practice, bedbank and hotel contracts commonly stop you from showing a net-based price below the hotel’s public rate as a standalone room, while allowing it inside a package or to a closed user group, such as a loyalty program redeeming points for hotels. Terms differ by contract and destination, so check your own contract before you set your markup rules. Our guide to travel API pricing models compares net rates with commission, subscription and per-call fees.

How Travel Agencies Buy Through a Bedbank API

Buying through a bedbank API follows the same shape at almost every supplier. The names of the calls differ; the order does not.

1. Open a trade account. Company details, licences where your market needs them, and a commercial agreement. Your payment terms are set here.
2. Get test credentials. Most bedbanks give a test environment first and live access later.
3. Download static content. Hotel names, addresses, geocodes, photos, descriptions and amenities, usually through a content API or a bulk file refreshed on a schedule.
4. Search availability. Send a destination or a hotel list, dates and occupancy; receive live rooms, board types, prices and cancellation terms.
5. Re-check the rate. Prices can change between search and booking. Hotelbeds, for example, flags some results with a rateType of “recheck” in its Booking API documentation and asks for a CheckRates call to confirm price and availability before booking.
6. Book. Send guest names and the rate key; receive a booking reference.
7. Issue the voucher or confirmation the guest shows at the hotel.
8. Service the booking. Retrieve, amend or cancel through the API, inside the deadlines in the rate’s cancellation policy.
9. Settle and reconcile. Pay by prepayment, deposit or credit line, then match invoices to bookings.

Steps 4 to 8 are what our hotel API integration guide covers call by call. A certification review before live access is common: the supplier checks that your flow re-checks prices, sends correct guest data and handles cancellations properly.

What Does a Bedbank API Return?

A bedbank API returns two kinds of data that behave very differently. Static content (hotel names, addresses, photos and amenities) changes over weeks and should be downloaded and stored. Dynamic rates (price, availability, board basis and cancellation policy) change by the minute and must be queried live at search time. Policies and booking data sit between the two.

Data	Examples	How often it changes	How to handle it
Static content	Hotel name, address, geocode, star rating, photos, descriptions, amenities, room names	Weeks or months	Download, store and refresh on a schedule
Dynamic rates	Price, currency, availability, board basis, rate plan	Minutes	Query live at search time; never show a stale price
Policies	Cancellation deadlines and penalties, payment type, taxes and fees	Per rate	Store with the booking and show at checkout
Booking data	Booking reference, status, voucher, supplier reference	Per booking	Keep for servicing and reconciliation

The split matters for cost and accuracy. Requesting static content on every search wastes your look-to-book allowance and slows your pages. Caching prices does the opposite damage: it sells rooms at yesterday’s rate. Cache content, query prices.

Watch the fields that never line up between suppliers: board codes (“BB”, “Bed and breakfast”, “Breakfast included”), room names (“Deluxe King”, “DLX KNG”), tax handling, and cancellation rules written as free text. With one bedbank you learn one dialect. With three, you translate three, which is where the decision in the next sections begins.

Which Bedbanks Sell Rooms to Travel Agencies Through an API?

Bedbanks and B2B hotel platforms that sell rooms to travel agencies through an API include Hotelbeds, WebBeds, TBO, GRN Connect and RateHawk; each needs a trade account and its own contract. The table below is a selection, not a census. Tripgic is listed first, as an aggregator API rather than a bedbank: it puts many hotel suppliers behind one integration.

Provider	What it is (quoted text is its own words)	Its headline figures	API access
Tripgic	A unified travel API; “a technical intermediary and aggregator, not a direct travel operator”	2M+ properties from 50+ suppliers in 190+ countries	One REST/JSON API; free sandbox
Hotelbeds	A B2B solutions provider “for wholesalers, supply partners and destinations”	c. 60,000 travel distributors; 170+ countries	“API Suite”, with public developer documentation
WebBeds	“A global B2B travel marketplace servicing the travel trade”	500k+ hotels; 50k+ travel buyer partners	Buyers “integrating through an API or booking online”
TBO	A global travel distribution platform for retail and API buyers	159,000+ buyers; 1 million+ suppliers; 100+ countries	“TBO APIs”
GRN Connect	“An online B2B hotel booking portal”	500K hotels; 200K apartments	Enquiry through its “API Connect” section
RateHawk	An “online booking tool for travel professionals”	3.3M+ hotels from 330+ suppliers	“API solutions” for partners

Figures are each provider’s own public claims, read on its own website on 3 November 2026. The Tripgic row comes from tripgic.com.

In short: Hotelbeds publishes its booking flow openly, including the recheck step above. WebBeds sells only to the trade, by API or website. TBO serves both agents who book by hand and API buyers. GRN Connect pairs hotels with apartments. RateHawk offers API access beside an affiliate route. The inventory figures are not comparable: one counts hotels, another properties, and the same hotel often sits in several lists.

One Bedbank, Many Bedbanks or an Aggregator: Which Should You Use?

A travel seller can buy hotel rooms three ways. One bedbank means one contract, one integration and one settlement account, but coverage is limited to that supplier’s contracts. Several bedbanks, direct widen coverage and let you compare sources for the same hotel, but each extra supplier adds a contract, an integration in its own format, a certification, a credit line and the job of mapping duplicate hotels and rooms. A hotel API aggregator connects to many suppliers, often including several bedbanks, and gives you one agreement, one integration and one data format, with most of the mapping done on its side. For a growing OTA, agency or startup without a supply team, the aggregator is usually the practical start. Direct bedbank contracts make sense later, in the destinations where your own booking data shows enough volume to pay for the extra work. The choice is really about how much supply work you want to own.

	One bedbank	Several bedbanks, direct	Hotel API aggregator
Contracts	One	One per bedbank	One
Integrations to build	One	One per bedbank, each in its own format	One
Inventory breadth	One supplier’s	Wider, with overlaps	Many suppliers’
Comparing two sources for one hotel	Not possible	Possible after you map hotels and rooms	Depends on the aggregator
Hotel and room mapping	Not needed	Your job	Largely the aggregator’s job
Credit and settlement	One account	One per bedbank, often in several currencies	One account
Certification	One	One per bedbank	One
Typical time to first booking (varies by supplier)	Weeks	Months for the full set	Days to weeks
Who it suits	A focused seller with one main supplier	A large OTA with an in-house supply team	A growing OTA, agency or startup that wants breadth without a supply team

The time row is a typical pattern, not a promise: every supplier and aggregator sets its own onboarding. For one example, Tripgic’s Hotel API page says teams typically go from first call to a test booking in days, and its pricing page says most activations complete within 3–5 business days.

No column is right for everyone, and many sellers pass through all three over the years. The next three sections show where each one fits, what breaks as you move from one to the next, and how to tell when it is time to move.

When One Bedbank Is Enough

A single bedbank is a sound start for many sellers. It works well when:

• You sell a small number of destinations where that bedbank has strong, directly contracted hotels.
• Hotels are part of a package, such as a tour operator selling holidays to a few resort areas, so the room price is not compared line by line.
• Your team is small. One contract, one integration, one invoice and one support desk keep the operation simple.
• Your volume is low and you would not meet the minimums or look-to-book terms of several suppliers.

The limits show up as you grow. Customers search for hotels the bedbank does not carry. A competitor shows a lower price for the same room from a different source. A peak-season sell-out at your only supplier becomes your sell-out. And your margin in every city rests on one supplier’s rates.

The signal that one bedbank is no longer enough usually sits in your search logs: a rising share of searches that return few or no results, or the same handful of properties losing on price to the same competitor week after week.

What Changes When You Add a Second and Third Bedbank

Adding bedbanks multiplies supply, and it multiplies work. The hard part is not the second integration itself; it is everything around it.

Duplicates. The same hotel arrives from two or three bedbanks under different IDs, spellings and coordinates. Without matching, your results page shows “Hotel Lisboa Centro”, “Lisboa Centro Hotel” and “H. Lisboa Centro” as three hotels. Our guide to hotel room mapping explains property, room and rate matching step by step.

Room and board translation. One supplier’s “Superior Double, BB” is another’s “Double Room Superior with Breakfast”. Comparing price means comparing the same room on the same board.

Policy normalisation. Cancellation rules arrive as structured deadlines from one source and free text from another. Your checkout must show one clear rule.

Routing. When two suppliers offer the same room, you need a rule for which one gets the booking: lowest price, the most flexible cancellation terms, or the strongest record of confirmed bookings.

Money. Each bedbank has its own credit limit, deposit, currency and invoice format, and reconciliation grows with every supplier.

Large OTAs build whole teams for this. For most sellers it is the main reason to look at an aggregator. Our piece on multi-supplier travel inventory covers routing and settlement in more depth.

What a Hotel API Aggregator Takes Off Your Plate

A hotel API aggregator connects to many hotel suppliers and gives you one integration and one data format on top. Tripgic’s Hotel API page puts it plainly: an aggregator “combines rooms from many suppliers — bedbanks, wholesalers, chains and regional providers — behind one integration and one data format”.

What that removes from your side:

• The supplier contracts. One agreement with the aggregator replaces a contract, credit terms and an integration per bedbank.
• The format work. Every supplier’s rooms, rates and policies arrive in one schema, so your front end reads one response.
• The certification queue. You certify once, with the aggregator, not with each supplier.
• The settlement spread. One account and one balance replace several credit lines.

What it does not remove: you still choose your markup, design your search and checkout, look after your own customers and test your flow. You still need to check rate quality in your own destinations, because a large global count can be thin in one city. And aggregators differ in model: some sell supply they have contracted, while others ask you to bring your own supplier contracts and only provide the connection. Ask which one you are buying. Our explainer on what a travel API aggregator is covers the model across flights and hotels.

Should a Growing OTA Use an Aggregator or Sign Direct With Bedbanks?

A growing OTA without a supply team is usually served by starting with an aggregator and adding direct contracts only where its own data proves the case. Here is how to tell which side of that line you are on.

Question	Points to an aggregator	Points to direct bedbank contracts
Do you have a supply or contracting team?	No	Yes, with mapping and finance support
How many destinations do you sell?	Many, spread out	A few, with high volume in each
Do you also sell flights, transfers or activities?	Yes, and one API can cover them	No, hotels only
How fast must you launch?	Weeks	Months are acceptable
Can you carry several credit lines and currencies?	Not yet	Yes
Do you know which suppliers win in your markets?	Not yet	Yes, from your own booking data

The path many sellers follow has three stages. Launch on an aggregator to reach broad inventory through one integration. Measure which destinations and hotels bring your bookings and where your prices lose. Add direct contracts, with a bedbank strong in one region or a hotel group you sell often, only where volume justifies the extra contract, integration and reconciliation.

Hybrid is normal. Large sellers commonly run an aggregator for breadth and direct contracts for their top destinations side by side. The question is not which model is right forever, but which one fits your current volume and team. For the OTA side of the decision, see our guide to travel APIs for OTAs.

A Worked Example: Three Cities, Three Routes

Take a growing OTA selling city breaks to London, Dubai and Bangkok, with the rest of the world on request. It wants hotels live in its app within a quarter. The outcomes below are illustrative, not quotes from any supplier.

Route 1: one bedbank. The OTA signs with one wholesaler that is strong in the Gulf. Integration and certification take some weeks. Coverage in Dubai is good; in London and Bangkok, many searches for mid-range central hotels come back thin. Settlement is one prepaid account in one currency.

Route 2: three bedbanks, direct. The OTA adds a Europe-strong and an Asia-strong wholesaler. The coverage gaps close. But the same London hotel now appears three times, room names differ, and one supplier’s cancellation rules arrive as free text. The OTA needs a mapping service or an in-house matching job, three certifications, three credit lines and three invoice formats. The project runs for months.

Route 3: one aggregator. The OTA signs one agreement with a hotel API aggregator and builds one flow (search, rooms, price check, book, voucher, cancel) against one schema. It tests in a sandbox, compares live rates for its three cities with its current source before paying, and goes live when its flow passes testing.

	Route 1	Route 2	Route 3
Contracts	1	3	1
Integrations	1	3	1
Mapping work	None	High	Low on your side
Settlement accounts	1	3	1
Coverage	Narrow	Broad	Broad

A year later, if Dubai has grown to half its hotel revenue, the OTA can add one direct contract there and keep the aggregator for everything else.

Which Bedbank Contract Terms Should You Read Before You Sign?

Whether you sign with a bedbank or an aggregator, the agreement decides your margin and your risk more than the API does. Read these terms line by line:

• Payment terms. Prepayment, deposit or credit line? How quickly must you pay, and what happens to bookings if a payment is late?
• Rate display rules. Where may you show a net-based price: open web, app, closed user group, packages only? Breaking these rules can end the contract.
• Cancellation deadlines. The supplier’s deadline is often earlier than the hotel’s. Set your own customer deadline before it.
• Look-to-book ratio. How many searches you may run per booking, and what happens if you go over.
• Certification. What the supplier checks before live access, and how long it takes.
• Currency. Which currencies you can buy in, and who carries the exchange risk.
• Content licence. Whether you may store and show hotel photos and descriptions, and for how long.
• Liability and service. Who handles a walked guest, an overbooking or a hotel closure, and how fast.
• Exit terms. Notice periods, and what happens to future-dated bookings if either side ends the agreement.

Ask for the draft contract early. Terms that sound small on a sales call can decide whether the whole model works for you.

What Is a Look-to-Book Ratio and Why Do Suppliers Care?

A look-to-book ratio is the number of searches a supplier allows you to send for each confirmed booking. Every search costs the supplier computing time and calls to hotels and to its own suppliers, so the ratio is written into the contract to protect that cost. If you send many times more searches per booking than it allows, expect a warning, a throttle or a fee.

Ratios matter more with hotel supply than most new sellers expect, for three reasons:

1. Metasearch and price comparison traffic creates huge search volume for each booking.
2. Several suppliers in parallel multiply your searches, because each user search fans out to every source.
3. Poor caching of static content sends calls that never needed to happen.

Three habits keep you inside the limit. Cache static content and search live only for prices. Send a search only when the user has given dates and occupancy. And on a results page, ask for full rate detail only for the hotels the user opens.

Tripgic’s API documentation says throughput “is provisioned to your expected volume and the look-to-book (L2B) ratio set out in your agreement”, so agree your expected volume during onboarding, not after launch.

What Are the Risks of Buying From a Bedbank?

Bedbank supply works well at scale, and it has known failure points. Plan for each one before launch.

Price change between search and booking. Rates move. A room priced at search can cost more at booking. A sound flow re-checks price and policy before it takes payment and shows the customer the final amount. Never charge on a search price.

Overbooking. A room can sell out at the hotel before the supplier’s availability updates. Book right after payment, handle a failed booking cleanly, and keep a re-accommodation process for the rare guest who is turned away.

Rate leakage. Net rates meant for packages sometimes appear as standalone rooms on public sites below the hotel’s own price. Hotels notice, and may close rates to that channel, and bedbanks police it too: in a 2019 Hotelbeds report covered by Travolution, its product director called wholesale rates promoted “unbundled on online public websites” “a huge problem”, and the article reports that Hotelbeds was “imposing penalties on clients that breach BAR (Best Available Rate) distribution agreements”. Follow your display rules.

Supplier outage. A supplier’s API can slow down or go offline. With one supplier your hotel sales stop; with several you need fallback routing.

Content errors. Wrong photos or amenities bring complaints and refunds. Give customers a way to report errors, and fix them at the source.

How Does Tripgic Supply Hotel Rooms?

Tripgic is not a bedbank. It is a unified travel API and, in its own words, “a technical intermediary and aggregator, not a direct travel operator”. Tripgic provides the connection, the normalisation and the developer tools. For hotels, that means:

• Many suppliers, one agreement. The Hotel API aggregates 2M+ properties from 50+ suppliers in 190+ countries. Tripgic’s hotel page sets this against connecting directly, where each bedbank means “a contract, credit terms and an integration”.
• One normalised schema. Every supplier’s rooms come back in one JSON format: hotel name, star and guest ratings, geocoded location, amenities, room imagery, rate plans, structured cancellation policies and a booking token.
• Rate plans as fields. Room-only, bed and breakfast, half board, full board, all-inclusive, advance purchase, non-refundable and member rates, each with deadline timestamps and penalty amounts.
• One booking flow for every supplier. The API documentation lists the hotel endpoints in order: location auto-suggest, search, rooms, hotel details, price and policy validation, traveller update, booking, booking details, voucher issue and cancellation. Prices returned at validation and booking are final.
• The net-rate model, kept. You receive the supplier net rate plus one flat markup per room night, never a percentage commission, and set your own selling price on top. Fee details are on the pricing page.
• Repricing from the same calls. For refundable bookings you can re-run search and price check for the same stay; if a lower rate appears before the cancellation deadline, book it and cancel the original. Our guide to the hotel repricing API shows how to run that check as a scheduled job.
• Prepaid settlement. One prepaid e-wallet: the net rate plus the flat fee is deducted automatically as each booking is processed. Detailed settlement terms are set out in your commercial agreement, as the pricing page explains.
• Test before you pay. Sandbox credentials are free, and a Live Rate Check Panel lets you compare live hotel rates in your market with your current suppliers before any payment. Activation usually takes 3–5 business days.
• More than hotels. The same API sells flights from 700+ airline and LCC connections, plus transfers, activities, tours, rail, eSIM and visas: 73 endpoints across 8 product families, with code samples in PHP, Node.js and Python.

What does “one normalised schema” look like in practice? Here is the sample response on Tripgic’s Hotel API page, trimmed to the hotel and one room rate:

{
  "hotel_id": "TG-PAR-1407",
  "name": "Grand Boulevards Hôtel",
  "stars": 4,
  "location": { "city": "Paris", "country": "FR", "lat": 48.8718, "lon": 2.3458 },
  "rooms": [{
    "room_id": "DLX-KING",
    "name": "Deluxe King",
    "max_occupancy": 2,
    "rates": [{
      "plan": "refundable",
      "price": 186.00,
      "currency": "EUR",
      "breakfast": true,
      "cancel_by": "2026-05-04T23:59:00Z"
    }]
  }],
  "supplier": "normalized",
  "booking_token": "tg_b_a8f3…e2c1"
}

Compare that with the problems in the multi-bedbank section above. The board basis is a plain breakfast field instead of a supplier code, the cancellation deadline is a cancel_by timestamp instead of free text, and "supplier": "normalized" is the page’s own point: one schema, regardless of supplier.

How Do You Choose a Hotel Supply Route?

Choose on evidence from your own destinations, not on headline hotel counts: test real searches in your top cities, count the contracts and integrations each route needs, and read the contract terms before you sign. Use this ten-step checklist with any bedbank or aggregator:

1. List your top 20 destinations by expected bookings.
2. For each one, test real searches on real dates from each candidate source: coverage, price and cancellation terms.
3. Ask which properties in those cities are directly contracted.
4. Read the contract terms listed above, especially payment, display rules and cancellation deadlines.
5. Count the work: contracts, integrations, certifications, mapping and settlement accounts.
6. Check that you can test in a sandbox and compare live rates before paying.
7. Agree your expected volume and look-to-book ratio in writing.
8. Decide what else you will sell (flights, transfers, activities) and whether one API can cover it.
9. Plan your second stage: which destinations would justify a direct contract later.
10. Set a date to review suppliers against your own booking data.

Final Thoughts

A bedbank is the hotel wholesaler at the centre of B2B hotel distribution: it holds contracts with hotels and sells their rooms to the trade at net rates. One bedbank is a simple start. Several bedbanks give breadth at the cost of mapping, routing and settlement work. A hotel API aggregator gives breadth through one contract and one integration, and leaves you free to add direct contracts where your own data proves them.

For most growing OTAs and agencies, the practical order is: launch on an aggregator, measure, then go direct where volume earns it. To see how that works with live hotel rates in your own markets, book a demo with Tripgic, or read our guide to hotel API providers next.