What Travel middleware means
A booking website should not need to know whether a fare came from a GDS in EDIFACT-derived form, an airline's NDC XML API or a low-cost carrier's own JSON interface. Middleware hides that complexity. Front ends talk to one internal API; the middleware talks to everything else.
Its first job is normalisation. Suppliers describe the same thing differently: airport and hotel names, baggage rules, fare conditions and ancillary codes. NDC adds variation of its own, since airlines implement different schema versions and levels of servicing. Middleware maps all of this into a canonical model through supplier adapters, so results can be compared and stored consistently.
Its second job is caching. Live searches cost money and time, and many are repeated. Caching recent results reduces calls to suppliers and helps keep the look-to-book ratio within contract limits, with a live price check before booking.
Its third job is orchestration. A single user action may need several supplier calls in order: search, price, hold, pay, ticket, then update the record. For packages, flight and hotel calls must succeed together or be rolled back. Middleware also adds logging, monitoring, error handling and fallback rules, such as showing an "agent assistance required" message when a supplier does not support a change by API.
A travel aggregator sells this capability as a service; many larger sellers run their own middleware as well.
How Travel middleware works
Middleware sits in the middle of every request, translating, routing and recording as it goes.
- Receive a requestA website, mobile app, agent portal or partner API sends a search or booking request in the middleware's own format.
- Check the cacheFor searches, recent results for the same route, dates or hotel may be returned from cache, or used to decide which suppliers to query live.
- Fan out to suppliersAdapters translate the request for each relevant GDS, NDC airline, LCC or hotel source and send the calls in parallel.
- Normalise and mergeResponses are mapped to the canonical model, duplicates are removed, and business rules such as markups or preferred sources are applied.
- Orchestrate the bookingOn booking, the middleware sequences price confirmation, order creation, payment and ticketing, and handles failures or partial success.
- Log and monitorEvery call is recorded for reconciliation, support and supplier performance tracking.
Travel middleware in practice
Content selection rule: if the same fare is returned by both a GDS and the airline's NDC API, middleware might prefer the NDC offer; if prices differ, it shows the cheaper one. Such rules are set by the seller, not by the suppliers.
Illustrative normalisation: one supplier calls an airport "Sydney International Airport", another "Sydney Airport". Both are mapped to the IATA code SYD. Likewise, a checked-bag allowance described as "1PC" by one source and "23kg x 1" by another is converted to the same internal field.
Illustrative orchestration: for a flight-plus-hotel package, the middleware holds the hotel, creates the flight order, takes payment and issues the ticket. If ticketing fails, it cancels the hotel hold so the traveller is not charged for half a trip.
Who uses it
Advantages and limitations
Advantages
- Front-end teams build against one stable API while supplier integrations change underneath.
- Caching reduces supplier search costs and improves response times.
- A common data model makes reporting, reconciliation and customer service simpler.
- New suppliers can be added by writing one adapter instead of changing every application.
Limitations
- Cached prices can be stale, so final price checks are needed and some bookings will show price changes.
- Normalisation can drop supplier-specific detail unless the internal model is designed to keep it.
- Running middleware means maintaining many adapters as suppliers release new versions.
- Orchestration across several suppliers adds failure points that need careful error handling.
Frequently asked questions about Travel middleware
What is the difference between travel middleware and a travel API?
A travel API is an interface for requesting travel content or bookings. Middleware is the system behind such an interface that connects to many suppliers, converts their data and coordinates calls. A seller's middleware often consumes several supplier APIs and exposes one API of its own.
Why is normalising NDC and GDS content difficult?
GDS content follows fixed, field-based structures, while NDC lets airlines model offers, bundles and ancillaries in their own way, across several schema versions. Some airlines return free-text descriptions instead of standard codes. Middleware must map all of these into one model without losing details travellers need.
How does caching work in travel middleware?
The middleware stores recent search results, such as fares for a popular route and date, for a set period. Repeat searches are answered from the cache instead of the supplier. Before booking, a live price check confirms the offer, because airline and hotel prices change frequently.
Should a travel agency build its own middleware?
Usually only at scale. Building middleware means owning every supplier adapter, certification and update. Most small and mid-sized agencies use an aggregator or a platform that includes middleware, and consider their own layer when volumes, supplier count or custom rules justify a dedicated engineering team.
Own your travel platform outright
The Source Code Edition gives you the full codebase to host, customise and extend on your own infrastructure.
See the Source Code Edition