Travel XML API Integrations for OTAs and Aggregators

Travel XML API integrations connect a travel platform to suppliers that exchange data through XML protocols - the SOAP/XML used by major GDS providers (Amadeus, Sabre, Travelport, Worldspan, Galileo, Apollo, Abacus), the XML formats used by many bedbank APIs (HotelBeds historically, Expedia Partner Solutions for legacy integrations, regional bedbanks), and the XML in NDC airline distribution. XML remains the foundation of travel-supplier communication because the legacy GDS infrastructure was built around SOAP/XML and carries trillions of dollars in transaction value through these protocols. Modern travel platforms cannot avoid XML entirely; they integrate XML alongside JSON-based modern APIs through adapter layers that handle both protocols. This page covers what travel XML API integrations actually involve, the supplier landscape that uses XML protocols, the integration patterns that hold up in production, the operational challenges specific to XML, and the future direction as JSON gradually displaces XML in some areas of travel distribution. The companion guides for the broader API integration context are travel API integration as the cluster anchor for the broader XML/SOAP framing, travel API development services for the development side, real-time travel API integration for the runtime patterns, and travel API integration in PHP for the PHP-specific patterns. Cross-cluster reach into NDC explained covers the modern airline distribution standard that uses XML or JSON.

Why Travel Still Runs On XML

XML dominance in travel APIs reflects the industry's history rather than current technology preference. Understanding why XML remains central helps integration partners and operators make pragmatic decisions about supporting both XML and modern JSON-based APIs. The historical foundation traces to the 1960s and 1970s when GDS systems (Sabre, Apollo, Galileo, Worldspan, Amadeus) were built around mainframe-era data exchange standards. SOAP and XML emerged in the late 1990s and early 2000s as the standard for enterprise integration; the GDS systems migrated from earlier proprietary protocols to SOAP/XML during this period. The integration between airlines, hotels, GDS, and travel agents settled on SOAP/XML as the lingua franca by the mid-2000s. The installed base of XML integrations is enormous. Every major GDS has thousands of partner integrations through SOAP/XML. Every major airline distributing through GDS has SOAP/XML connections. Every travel agent ticketing through GDS uses SOAP/XML behind the scenes. The cumulative integration investment runs into many billions of dollars; replacing it would take decades and most stakeholders see no commercial benefit to doing so when the existing protocols work. The protocol stability matters for travel because bookings settle through complex multi-party relationships with regulatory oversight. SOAP/XML's verbose schemas and strict validation provide the contractual clarity that travel commerce requires. JSON's flexibility is convenient for modern APIs but the strictness of XML protocols is sometimes a feature rather than a bug for high-stakes commerce. NDC's XML choice is an interesting case. The NDC standard launched in the 2010s when JSON was already the modern default, but IATA chose XML for the standard partly because the existing airline IT systems were built on SOAP/XML and partly because XML's strict schema validation suits the contractual nature of airline distribution. Some NDC airlines now offer JSON variants; the standard supports both. The aggregator alternative wraps XML APIs into REST/JSON facades. Travelport, Sabre, and Amadeus all offer JSON-based aggregator APIs that hide the XML complexity from partners. Third-party aggregators like Duffel, Verteil, and others provide similar wrapping. The aggregator approach lets new platforms work in JSON without losing XML access; the underlying supplier connections still use XML. The cost-benefit reality for new integration projects favours XML where suppliers already use XML. Re-implementing the same content in JSON adds layers without delivering new capability. Building new content layers (NDC ancillaries, dynamic pricing, modern booking flows) in JSON makes sense; replacing existing GDS XML with JSON for the same content does not. The skill base in travel-tech engineering teams remains XML-aware because the industry runs on XML. Engineers who only know JSON-based modern APIs face a learning curve when integrating travel suppliers; teams that maintain XML expertise alongside JSON skills work effectively across the supplier landscape. The honest framing is that travel XML APIs are not legacy in the negative sense - they are working production infrastructure that delivers daily commerce. Operators integrating travel suppliers will work with XML because the suppliers use XML; resisting XML is resisting the industry's reality. The cluster guide on travel API integration covers the broader XML/SOAP integration context, and the cross-cluster JSON-based modern alternatives are in NDC explained for OTAs.

The cluster guides below cover the XML API integration patterns, supplier connectors, and broader API integration context.

The XML Supplier Landscape

Travel suppliers using XML protocols span the major GDS providers, many bedbanks, and increasing NDC airline distribution. The supplier landscape determines what XML expertise the integration team needs. Amadeus Web Services covers Amadeus's flight, hotel, car rental, rail, and other content through SOAP/XML. The API surface is deep with hundreds of distinct services across the booking lifecycle - search (FareMasterPricer, FareInformativePricingWithoutPNR), booking (PNR creation through PNR_AddMultiElements), ticketing (DocIssuance_IssueTicket), servicing (PNR_DisplayHistory, PNR_Cancel, PNR_NameUpdate), and many more. Amadeus offers JSON variants for some services through Amadeus for Developers but the full Amadeus Web Services surface remains XML-native. Sabre Web Services provides Sabre's airline, hotel, and car content through SOAP/XML. Major services include BargainFinderMax (flight search), EnhancedAirBook (booking and ticketing), HotelAvailRQ (hotel search), GetReservation (PNR retrieval), and many servicing-related services. Sabre also offers REST variants alongside SOAP/XML for some services. Travelport Universal API provides Travelport's content through SOAP/XML across the Travelport portfolio (formerly Galileo, Worldspan, Apollo plus the unified platform). The Universal API attempts cross-vendor consistency but supplier-specific differences remain visible in the responses. Worldspan, Galileo, and Apollo as separate brands have largely consolidated into Travelport's Universal API, though some legacy connections exist with the brand-specific APIs. Abacus serves Asian markets and is part of Sabre. HotelBeds API historically used SOAP/XML for its hotel inventory; the platform has migrated extensively to REST/JSON in recent years but XML support continues for legacy partners. Expedia Partner Solutions serves partners with extensive XML integration history; the platform's modern APIs lean toward JSON but XML remains supported. Bedbank APIs from many regional providers use XML, particularly older platforms. NDC airlines use XML for the offer-and-order flow per the NDC standard's XML schemas. Each airline implements NDC with its own quirks; the integration is per-airline despite the standard. Direct airline pre-NDC APIs on some carriers use XML; these are gradually migrating to NDC or being deprecated as airlines consolidate distribution. Cruise lines, activity providers, and rail operators have varying API protocols. Some use XML, some REST/JSON, some have proprietary formats. The XML integration team needs to handle each supplier's specific protocol. The supplier mix decision for an OTA depends on the operator's commercial strategy. Most platforms integrate one or two major GDS providers (Amadeus and Sabre being the most common combination) plus selected NDC airlines plus aggregator-mediated long-tail. The mix produces broad coverage with manageable engineering effort. The XML expertise per supplier takes time to build. Amadeus's API surface alone is deep enough that becoming proficient takes months of sustained work; covering Amadeus plus Sabre plus Travelport plus several airline NDC implementations spans years of accumulated team knowledge. Operators benefit from working with travel-tech development partners that maintain this expertise rather than building it from scratch. The cluster guide on Sabre software covers Sabre specifics, and the cross-cluster GDS-and-NDC channel mix is in airline API integration.

XML Integration Patterns That Hold Up In Production

Production-grade XML API integration follows patterns that distinguish mature implementations from prototype-grade work. The patterns matter because XML's verbose nature and supplier-side complexity amplify the cost of errors. Adapter framework architecture separates the XML-specific concerns from the platform's internal API. The adapter layer handles XML serialisation and parsing, schema validation, supplier authentication, request mapping, response normalisation, and error handling. Above the adapter, the platform sees a clean internal API that does not change when a supplier swaps. Travel-tech development teams that have built multiple integrations maintain reusable adapter frameworks that accelerate new integrations. Schema validation against the supplier's WSDL or XSD catches malformed requests before they hit the supplier. Strict validation during development catches integration errors early; relaxed validation in production tolerates supplier-side schema drift that strict validation would reject. The right balance depends on the supplier's update cadence and the platform's tolerance for breakage. Authentication patterns vary per supplier. WS-Security tokens for SOAP services with their own token lifecycle, session-based authentication with login and refresh sequences, custom header schemes, OAuth for some modern XML APIs, and combinations across services within the same supplier. The adapter manages authentication transparently; the booking flow does not see authentication complexity. Request mapping translates the platform's internal model to the supplier's specific request format. The mapping handles supplier-specific quirks - which optional fields are required by this supplier despite the schema marking them optional, which date formats the supplier expects, which character encoding handles travellers' names with diacritical marks. Response normalisation transforms the supplier's response into the platform's internal model. Different suppliers represent the same content differently - airline codes, fare classes, ancillary types all vary. The normalisation layer produces a consistent representation regardless of supplier. Error handling distinguishes transport errors (network failures, timeouts), protocol errors (HTTP status codes, SOAP faults), schema errors (malformed XML, validation failures), and business errors (the response succeeds but contains an error code). Each category needs specific handling - transport errors retry with backoff, protocol errors may indicate authentication issues, schema errors flag for engineering review, business errors map to user-facing messages. Idempotency on booking operations prevents duplicate bookings on retry. The adapter generates idempotency keys per logical operation; the supplier respects the key by returning the original response on repeat calls. Critical for ticketing operations where duplicate calls could create double-charged tickets. Logging and observability capture full request and response XML for production debugging. Travel commerce disputes (with airlines, payment providers, regulators) require the platform to produce the exact XML exchanged during the booking. The audit log retention period typically follows IATA's 7-year requirement for ticketed bookings. Performance optimisation for XML processing matters at scale. XML parsing with DOM (loads entire document into memory) versus SAX or pull parsing (streaming) affects latency and memory under high load. Travel-tech development teams use XML libraries chosen for their performance characteristics; some teams build custom parsers for the specific subset of XML the supplier returns. Schema evolution handling manages supplier-side changes. Suppliers update WSDLs and XSDs over time; the adapter must continue working as new optional fields appear, deprecated fields are removed, and field semantics shift. Versioned adapters with migration testing protect against schema-related breakage. The cluster guide on travel API development services covers the broader integration patterns, and the cross-cluster reach into real-time travel API integration covers the runtime resilience patterns.

The XML-Plus-JSON Hybrid Future

Travel APIs are not migrating wholesale from XML to JSON; they are evolving into a hybrid landscape where modern platforms handle both protocols across their supplier mix. The trend matters for operators planning long-term integration strategy. JSON growth in travel APIs is real and continuing. Major GDS providers (Amadeus for Developers, Sabre's REST APIs, Travelport's modern APIs) offer JSON variants for many services. Aggregator wrappers (Duffel, Verteil, others) provide JSON-native interfaces over XML supplier APIs. New supplier APIs increasingly default to JSON. The trend reflects developer preference and the broader industry's JSON dominance for new APIs. XML persistence in travel runs deeper than the migration speed suggests. The legacy GDS infrastructure carries decades of XML investment; the cost of replacing equivalent functionality in JSON exceeds the benefit. NDC's XML standard is staying XML for the foreseeable future. Long-tail suppliers (smaller bedbanks, regional aggregators, cruise lines, activity providers) maintain XML APIs because their partners use XML. The XML integration work is permanent infrastructure for travel platforms. The hybrid integration architecture handles both protocols through the adapter layer. The platform's internal API stays consistent; the adapters per supplier handle XML or JSON or both depending on the supplier's offering. New integrations may default to the JSON variant of a supplier's API where available; legacy integrations continue on XML where the JSON variant does not yet cover the required functionality. The engineering team's expertise needs to span both protocols. Teams that only know JSON-based modern APIs cannot integrate XML-only suppliers; teams that only know XML lose ground as new APIs default to JSON. Travel-tech development teams maintain dual expertise as a core capability. The performance characteristics differ between XML and JSON. JSON's lighter syntax produces smaller payloads (typically 30 to 60 percent smaller than equivalent XML) and faster parsing. For high-throughput search operations, JSON's performance advantage matters; the platform's resilience patterns (caching, parallelism, fallback routing) compensate for XML's overhead at scale. The schema evolution patterns differ. XML schemas (XSD/WSDL) provide strict contractual definition; supplier-side changes require explicit schema updates that consumers must match. JSON's looser typing tolerates incremental field additions but offers less contractual clarity. Travel commerce favours the XML strictness for high-stakes operations; modern JSON APIs sometimes lose context that XML carried explicitly. The tooling differences matter for development. XML tooling (XML Spy, oXygen, schema-aware editors) supports XML-specific patterns. JSON tooling is generally more abundant in modern development environments. The development team's tooling investment differs between XML-heavy and JSON-heavy work. The operator's planning horizon for XML versus JSON should expect XML to remain through the 2030s and beyond. Investments in XML expertise, adapter frameworks, and supplier integrations continue paying back; assumptions that XML will disappear are wishful thinking. The platforms that win plan for hybrid integration as a permanent state rather than a transitional phase. For new platform builds, the right approach defaults to JSON for new APIs while accepting that core supplier integrations will be XML. The platform's internal architecture should normalise both protocols through adapters; the team's hiring should weight both XML and JSON expertise. Operators that try to avoid XML by limiting supplier integration to JSON-only suppliers cap their addressable supply unnecessarily. The honest framing is that travel XML API integration is not going away. The XML-plus-JSON hybrid is the lasting state of the industry. Operators that embrace hybrid integration build durable platforms; operators that try to avoid XML lose access to substantial supply or face migration projects when their JSON-only assumptions fail. The cluster anchor on travel API integration covers the broader XML/SOAP framing, and the cross-cluster modern airline distribution is in NDC explained. Travel XML API integrations done well are foundational infrastructure for any travel platform with serious supplier reach; the operators who invest in XML expertise alongside modern JSON skills build platforms that integrate the full travel-supplier landscape rather than the JSON-only subset.

FAQs

Q1. What are travel XML API integrations?

Travel XML API integrations connect a travel platform to suppliers that exchange data through XML protocols - typically SOAP/XML for legacy GDS providers (Amadeus, Sabre, Travelport, Worldspan, Galileo, Apollo, Abacus) and many bedbank APIs. The integration involves XML parsing, schema validation, request mapping, response normalisation, and operational discipline.

Q2. Why does travel still use XML rather than JSON?

Major GDS systems were built decades ago when SOAP/XML was the standard for enterprise integration. The legacy systems carry millions of integrations and trillions of dollars in transactions through XML protocols; replacing them with JSON would be a multi-decade industry effort. Travel XML remains because the cost of replacing it exceeds the cost of maintaining it.

Q3. What XML APIs do travel platforms typically integrate?

Amadeus Web Services API for flights, hotels, cars, and other Amadeus content; Sabre Web Services for similar coverage on Sabre; Travelport Universal API across the Travelport portfolio; HotelBeds API which has SOAP and REST options; Expedia Partner Solutions which moved toward JSON but supports XML for legacy integrations; bedbank APIs from regional providers; and direct airline XML APIs.

Q4. How long does an XML API integration take?

Aggregator wrappers around major XML APIs cut integration time to 4 to 8 weeks. Direct XML API integration with a major GDS or bedbank takes 8 to 16 weeks for first integration covering search, book, and basic servicing. Full lifecycle integration including all servicing flows extends to 4 to 6 months. Per-airline NDC XML integrations take 3 to 6 months each.

Q5. What are the operational challenges of XML APIs?

XML schemas are verbose - request and response messages are larger than JSON equivalents which affects bandwidth and parsing performance at scale. SOAP/XML services often require strict schema validation; supplier-side schema changes can break the integration without warning. Authentication patterns vary widely. Error responses sometimes return as HTTP 200 with error details embedded in the XML.

Q6. How do XML APIs compare to NDC and aggregator REST APIs?

Legacy XML APIs are deeper in feature coverage because they have decades of evolution. NDC standardises XML or JSON for direct airline distribution with richer offer-and-order semantics but each airline implements with quirks. Aggregator REST APIs simplify XML complexity through wrapper layers at the cost of additional fees and dependency.

Q7. What XML parsing libraries work for travel integration?

PHP's SimpleXML and DOMDocument for PHP-based platforms, Python's lxml for Python platforms, .NET's XmlDocument and LINQ to XML for .NET platforms, Java's JAXB for Java platforms. Travel-specific libraries built on top of these handle the supplier-specific patterns. Most travel-tech development partners maintain internal XML adapter frameworks they reuse.

Q8. How does an XML API integration handle errors and exceptions?

Layered error handling distinguishes transport errors (network failures, timeouts), protocol errors (HTTP status codes), schema errors (malformed XML, validation failures), and business errors (the API returns successfully but with an error code in the response). The adapter layer maps each error category to platform-internal error codes the booking flow handles consistently.

Q9. What is the future of XML in travel APIs?

XML is gradually giving way to JSON for new APIs, but the migration takes decades because of the legacy installed base. Major GDS providers offer JSON alternatives alongside XML for some services; NDC is XML-native but JSON variants are emerging; new APIs default to JSON. Travel platforms running today need to handle both XML and JSON.

Q10. Should an OTA integrate XML directly or use an aggregator?

Smaller OTAs benefit from aggregators that wrap XML complexity into simpler APIs at the cost of aggregator fees. Larger OTAs integrate XML directly to capture better economics and full feature access. Most platforms run hybrid - direct XML on the highest-volume suppliers where economics justify the work, aggregator-wrapped XML for the long tail of suppliers.