The short version
- There is no single “travel API”. There are four different supply models — GDS, NDC, consolidator and bedbank — and most agencies need two or three of them.
- Integration effort is rarely the hard part. Supplier onboarding, credentials, certification and settlement are what actually delay launches.
- Build a supplier-agnostic layer from day one. Agencies that hardcode one supplier rebuild within a year.
- The cheapest fares usually sit outside the GDS — in low-cost carrier content and NDC direct connections.
“Travel API integration” is one of those phrases that sounds like a single task and turns out to be a dozen. Connecting a flight API is not the same job as connecting a hotel bedbank. Getting search results back is perhaps a fifth of the work; the rest is booking, cancellation, refunds, vouchers, reconciliation and the long tail of edge cases that only appear once real customers are paying real money.
This guide covers what actually matters: the supply models available in 2026, what each supplier will ask of you, how the money moves, and the failure modes that catch teams out. It is written from the perspective of running a live platform rather than selling one.
The four supply models, and why the distinction matters
Almost every travel API falls into one of four categories. Choosing the wrong one for your market is the single most expensive mistake in this space, because it determines your fares, your margins and your obligations.
1. GDS (Global Distribution Systems)
Amadeus, Sabre and Travelport are the traditional backbone of airline distribution. They aggregate published fares from hundreds of carriers into one interface, and they remain excellent for complex itineraries, multi-city routing and corporate travel where change and refund handling matters.
Their weaknesses in 2026 are well known. Low-cost carriers are largely absent, airlines increasingly reserve their best fares for other channels, and access typically requires accreditation plus a commercial agreement with meaningful volume commitments. For a new agency, the GDS is rarely the first connection.
2. NDC (New Distribution Capability)
NDC is the airline industry’s XML-based standard for distributing content directly, bypassing the GDS layer. In practice it means richer content (seat maps, baggage, branded fares, ancillaries) and often lower fares, because airlines use it to reward direct relationships.
The catch is fragmentation. Every airline implements NDC slightly differently, and building direct connections to twenty carriers is twenty integrations. This is why NDC aggregators exist — they normalise many carriers behind one API. If you want the cheapest airline fares in 2026, some NDC exposure is no longer optional.
3. Consolidators and aggregators
Consolidators hold their own airline contracts and resell to agencies at net rates. Companies like TBO, Mystifly and PKfare fall here. You get a single API, a single commercial relationship, and content that typically blends GDS, NDC, LCC and privately negotiated fares.
For most independent agencies in the GCC and South Asia, this is the pragmatic starting point. Onboarding is faster than the GDS, accreditation is usually not required because the consolidator holds it, and the API surface is a single integration rather than several.
4. Bedbanks and wholesalers (hotels)
Hotels work differently from flights. Bedbanks such as Hotelbeds, RateHawk and Stuba contract inventory in advance and resell it at net rates. You add your own margin and sell at whatever price you choose. There is no equivalent of “published fare” discipline — your sell price is genuinely yours.
The practical rule: flights are a thin-margin, high-complexity product where you rely on someone else’s contracts. Hotels are a higher-margin product where you control pricing. Most agencies make their money on hotels and their reputation on flights.
What suppliers actually require before they give you keys
This is the part that surprises people. The technical integration might take a few weeks. Getting to the point where you are allowed to integrate can take longer.
| Requirement | What it means in practice |
|---|---|
| Commercial agreement | Almost every real supplier requires a signed contract before issuing production credentials. Test keys are often available earlier. |
| Company verification (KYC) | Trade licence, ownership documents, sometimes proof of address and bank details. Jurisdiction matters — some providers do not onboard companies from certain countries at all. |
| Certification | Several suppliers review your integration before going live. Hotelbeds, for example, has a formal certification process covering workflow, mandatory voucher fields and cancellation handling. |
| Deposit or credit line | Consolidators and bedbanks typically run a prepaid wallet model. You fund a balance and bookings draw from it. This is working capital, not a fee — but it is cash you must have. |
| Local licensing | Selling travel usually requires a travel agency or tour operator licence in your jurisdiction, independent of anything the supplier requires. |
The lesson: start supplier conversations before you start building. Development can proceed against test credentials, but nothing ships until the commercial side clears.
The architecture decision that saves you later
The most valuable structural choice in a booking platform is to keep suppliers behind a common interface. Every supplier gets an adapter that exposes the same operations — search, price check, book, retrieve, cancel — and the core platform never knows which supplier it is talking to.
This sounds like over-engineering when you have one supplier. It stops sounding like that the first time any of the following happens, and one of them always does:
- A supplier declines to onboard your company, and you need a different one.
- A supplier’s coverage is weak on your main routes and you want to compare two in parallel.
- A supplier changes commercial terms and your margin evaporates.
- You want to sell in a second market where your existing supplier has no content.
With an adapter layer, adding a supplier is writing one file. Without it, adding a supplier means touching search, booking, payment, documents and cancellation. The difference is weeks versus months.
A related benefit: with several suppliers connected, a single search can fan out to all of them in parallel and return the cheapest confirmed result. That is not just a technical nicety — multi-supplier comparison is how you actually deliver competitive prices, rather than hoping one provider happens to be cheap on every route.
What breaks in production (and rarely in the docs)
These are the issues that consume real time after launch. None of them are exotic; all of them are routinely underestimated.
Currency mismatch
Suppliers price in their own currency. A bedbank might return EUR while your customer expects AED. If you display a converted price but charge and invoice in the supplier’s currency, customers see one number and their bank shows another. Decide early on a single settlement currency that the customer sees, pays and is invoiced in, and convert supplier prices at the point of pricing.
Price changes between search and booking
Cached availability goes stale. Most hotel APIs require a re-check call before booking, and some flight suppliers re-quote at ticketing. Your flow must handle “the price went up” gracefully — show the new price and ask the customer to confirm, rather than silently charging more or failing the booking.
Passenger detail rules
Child ages are mandatory for most hotel and activity suppliers, and they must match what was searched. Passenger name formats, document requirements and age thresholds vary by supplier and by product. Collecting “2 adults, 1 child” without the child’s age will fail at booking.
Timeouts and partial failures
Booking calls can take 30 to 60 seconds. A timeout does not necessarily mean the booking failed — it may have succeeded on the supplier side. Your system needs to reconcile rather than assume, or you will create duplicate bookings and phantom charges.
Vouchers and documents
Some suppliers return their own PDF voucher which you are contractually required to give the customer instead of generating your own. Miss that rule and the customer arrives with a document the operator will not honour.
Cancellation and refund flows
Cancelling with the supplier is only step one. You then need to work out what the customer is actually owed after penalties, refund them through the original payment method or wallet, and reflect it in your accounts. Many platforms launch with a cancel button that only tells the supplier and leaves the money unreconciled.
How the money actually moves
Understanding settlement prevents unpleasant surprises. There are broadly two models.
Prepaid wallet. You hold a balance with the supplier. Each booking deducts the net amount. You collect the full retail price from the customer through your own payment gateway and keep the difference. This is the common model for consolidators and bedbanks. The implication is working capital — you need funds parked before you can sell.
Pass-through or agency billing. The supplier bills you periodically, or the customer’s card is charged directly by the supplier. Less common for smaller agencies, and it changes who carries chargeback risk.
Either way, you need your own payment gateway to collect from customers, and it must support presenting the currency you sell in. Gateways settle to your bank account in specific currencies; confirm this matches your settlement currency before you launch.
A checklist to use before you sign with any supplier
- Coverage: which airlines, hotels or products, specifically on the routes and destinations your customers actually book?
- Content type: GDS, NDC, LCC, net or private fares? For hotels, contracted or resold?
- Onboarding: will they accept a company incorporated in your country? Ask directly rather than assuming.
- Certification: is there a review process before production access, and what does it test?
- Settlement: deposit required, credit terms, and which currency you are billed in.
- Cancellation: is it available by API, or does it require emailing an operations desk?
- Documents: do they supply vouchers you must pass through, or do you generate your own?
- Support: what happens at 2am when a booking is stuck and a customer is at the airport?
- Rate limits: searches per second, and whether caching is required or forbidden.
- Exit: notice period, and whether you keep access to historical booking data.
How long integration really takes
A rough guide, assuming a competent developer and an existing platform to integrate into:
| Stage | Typical duration |
|---|---|
| Supplier commercial agreement + KYC | 2–6 weeks (entirely outside your control) |
| Search + booking against test credentials | 1–3 weeks per supplier |
| Cancellation, refunds, documents, edge cases | 1–2 weeks per supplier |
| Certification, where required | 1–4 weeks, depending on reviewer turnaround |
| Live testing and reconciliation | 1–2 weeks |
Building the surrounding platform — user accounts, payments, markup rules, invoicing, agent wallets, admin tooling — is a substantially larger undertaking than the API integrations themselves. That is the calculation behind buying a platform rather than building one, and it is worth doing honestly before committing.
Where this leaves you
If you are starting out: pick one consolidator that covers your main market, one bedbank for hotels, and build behind an adapter layer so adding the third and fourth supplier is cheap. Get the commercial conversations moving before you write code, because they are the long pole.
If you are already live: the highest-value additions are usually a second flight source for price competition, and proper handling of the unglamorous flows — cancellation, refunds, reconciliation — which is where margin quietly leaks.
Frequently asked questions
What is a travel API?
A travel API is an interface that lets your booking platform search and book supplier inventory programmatically — flights, hotels, tours, car hire or transfers. Instead of logging into a supplier portal, your system sends a search request and receives structured results it can price, display and book.
Do I need IATA accreditation to sell flights?
Not necessarily. Consolidators hold their own accreditation and let you sell under it, which is how most independent agencies start. Direct GDS access and some airline connections do require your own accreditation. You will still need the appropriate travel or tourism trade licence in your own country.
How much does travel API integration cost?
Most flight and hotel suppliers do not charge per API call. They make money on booking margin, and typically require a prepaid deposit or credit line instead. Your real costs are development time, the working capital in your supplier wallet, and any setup fees the supplier applies. Metered per-request pricing is more common with data APIs than booking APIs.
Can I connect more than one supplier?
Yes, and you generally should. Multiple suppliers give price competition, coverage in more markets, and protection if one relationship ends. The requirement is an architecture that keeps suppliers behind a common interface, so adding one does not mean rewriting your booking flow.
How long does it take to launch?
For an existing platform, a single supplier integration is typically two to six weeks of development plus whatever the supplier’s commercial onboarding takes. Building an entire booking platform from scratch is a multi-month project before any supplier is connected.
See it working, not just described
Travelzop is a white-label travel platform built and run in the UAE — flights, hotels, tours, car hire and transfers, with your brand on it and the source code in your hands.
Talk to us →