A note before the article
Some articles are written from theory. This one grew out of real life experience and integration “scar tissue”.
I recently worked with the AltexSoft editorial and engineering teams on a deep dive into a question that sounds simple but is anything but: Why does a serious GDS integration still take the better part of a year—and can AI genuinely reduce that timeline without creating a faster route into production failure?
My contribution focused on the parts that are easily underestimated when an integration is described as “just connecting an API”:
- the end-to-end booking and servicing flow;
- normalization across EDIFACT, NDC and LCC content;
- failure scenarios;
- the commercial logic sitting behind the technical plumbing;
- and the guardrails required when AI touches fares, payments and ticketing.
In travel, a confirmed API response is not the same as a completed journey. You are not moving goods. You are moving people—and every element must still fit together when something changes halfway through.
The encouraging part is that development really can move much faster. AI-assisted engineering, knowledge graphs, reusable flow specifications and a properly captured edge-case knowledge base can compress months of integration work into weeks. But only when they sit on top of strong domain knowledge, a tightly scoped MVP and deliberate human oversight. AI can accelerate a sound system. It can also accelerate a bad one from bad to worse.
The article was first published by AltexSoft on 10 August 2026 and is now gated on their website. I am therefore making the complete piece available here as well, including the AltexSoft team’s original text and examples. Credit belongs to Olga Pereverzieva and the AltexSoft contributors Serhii Shkodenko and Oleksandr Hryhor, with whom the article was developed.
Enjoy the read.
Why GDS Integration Takes Months, and How to Cut This Time to Weeks
A travel agency integration with GDS travel APIs is typically a journey of 10 months to a year, from the first intake form to a live production environment. As an Authorized Sabre Developer, we built on top of them enough times to know that firsthand.
However, it’s totally feasible to reduce this timeframe by significantly speeding up the integration code development. For instance, by combining AI, a knowledge graph platform, and domain expertise, the AltexSoft engineering team cuts the integration with Sabre to 2-4 weeks (depending on specifics), with a 7x reduction in bug rate. In this article, we’ll dive deep into how exactly GDS integration timelines can be compressed.
What makes GDS integrations long and tricky
For OTAs and TMCs, GDS API integration is a reliable way to gain access to a broad range of airline, hotel, and car rental content. The business value is obvious, but connecting to such a complex and extensive platform requires significant resources.
Business negotiations are intensive
Before you can start integrating with GDS APIs, you must complete a business onboarding process that typically takes several months. This includes proving your legal business status, providing the required industry accreditations (such as ARC or IATA, or partnership with a consolidator), submitting an intake form, negotiating the APIs and geographic markets you need, and signing a commercial agreement covering pricing, usage, and legal terms. Only after the contract is finalized does the GDS grant access to its account management portal and API environment.
Read more about it in our experience-based piece on Sabre API Integration.
Working across two protocols has its complications
A GDS’s developer ecosystem offers tens or hundreds of APIs, both SOAP and REST (in case of Sabre, for instance, it’s 239 SOAP against 191 REST APIs). REST is the more modern, but it doesn’t cover every workflow, so most serious integrations end up working across both.
Besides being less developer-friendly, SOAP can create a second-order problem: for example, some Sabre SOAP APIs are very similar. And if you use AI coding tools, a large language model can easily pick the wrong API to integrate with (that’s what happened to our team, but human developers caught the mistake in time).
The booking flow is more complex than it looks
A successful integration depends on calling the right API endpoints in the correct order. Booking, pricing, ticketing, payment, and post-booking operations form a sequence in which each step affects the next.
Flight Booking Algorithm: Steps and Key Systems
Flight booking steps and key systems involved
Fritz Oberhummer, who runs a Strategy Advisory service for Product, Platform & AI, believes many teams underestimate the complexity of the end-to-end flight booking flow: “To get confirmation is not enough. You need to understand when fare details change, when payments fail, when a ticketing process is incomplete, or when airlines send schedule changes.“
Adding other travel products—hotels, cars, and ground transportation—introduces its own booking logic, including when payment is initiated, how cancellation policies are interpreted, and when funds are ultimately captured. Yet all these flows must remain synchronized from start to finish. “You’re not moving goods, you’re moving people in a certain place, at a certain time, with certain kinds of requirements”, reminds Fritz. “And all of the products along this journey always need to fit around the traveler and not the other way around. The quality of integration is one thing, making sure all is properly normalized and orchestrated still remains the other big piece that often gets overlooked and simply costs time.”
That’s why the scope needs deliberate planning. Here is what Fritz suggests.
Design for failure first. Before building booking flows, map everything that can go wrong—both within each supplier integration and when it interacts with other products.
Separate reusable infrastructure from custom business logic. The core booking plumbing may be reusable, but commercial rules and operational requirements usually are not. Every feature should support a clear, measurable business outcome and account for future iteration and technical debt. Aligned setting of KPIs between сommercial, product, technology, and marketing teams is a key component to building a scalable basis.
Start with a tightly scoped MVP. Always start with the “Rule of the Three”: Test the product with one market, one client, and one segment. Validate the commercial case and risks before expanding, as projects often fail when too many suppliers, processes, and departments are involved from the start.
The data is not 100 percent normalized
GDS’s core value proposition is aggregating content from multiple airlines and other suppliers behind a single point of access, eliminating the need for hundreds of separate integrations. But a common access point does not necessarily mean fully standardized content.
Airline data still varies significantly, particularly across NDC connections. Baggage allowances, fares, fare rules, taxes, and servicing capabilities may be structured or expressed differently by each carrier. Fritz adds that LCC (low cost carriers) might operate “at a very much reduced scope and different booking flow,, and they still need to be normalized against NDC and EDIFACT flows”.
Serhii Shkodenko, an AltexSoft engineer who has led multiple GDS integration projects, offers an example: “You might expect a specific piece of baggage information to appear at a particular location within the response for, let’s say, 97 percent of airlines that distribute content via EDIFACT. But for two or three percent, that same information may be found in a completely different field. With NDC airlines, it’s even worse: only about 70 percent of them follow an IATA standard for baggage data; others use their own rules.”
Fritz Oberhummer adds that “fare rules alone can run to a long list of conditions per fare, which is part of why Sabre offers a dedicated API—Fare Insight—built specifically to help normalize and interpret that complexity”.
Read the article on how AltexSoft approaches fixing EDIFACT and NDC content inconsistencies.
Edge cases are unpredictable
Edge cases are unexpected issues that show up only under specific conditions. These are rarely covered in the documentation and are usually discovered only during implementation.
One example concerns a delay between pricing and booking. It typically takes users 15–20 minutes to review the itinerary and enter passenger and payment details, and in this time, the fare class may change. As a result, the booking can fail because the originally priced flight is no longer available. One way to address this issue is to reprice the itinerary immediately before booking. If the fare has changed only slightly, some customers are willing to accept the higher price.
Other edge cases are specific to the combination of an agency account and an airline. Serhii shares one example of how a mismatch between airline-side defaults and account configuration can disrupt ticketing: “Say, when KLM or Air France creates a booking, the fare is returned in euros. But our client’s agency account requires tickets to be issued in US dollars. Because the booking and ticketing currencies did not match, ticket issuance repeatedly failed. The error messages did not clearly explain the cause, so it took time to trace the problem back to the conflicting settings and correct them.”
There are also GDS-specific quirks. According to Serhii: “During ticketing, you can’t fully trust what the endpoint tells you. If it returns certain errors, the ticket may have been issued anyway, but never made it into the PNR. In this case, the ticket numbers show up only in Sabre’s back-office sales report, not in the booking record itself”.
Sabre has a dedicated term for this state, ghost ticketing, and gives the developers access to an internal API to detect and prevent this issue.
These are only some examples of non-obvious behavior that any GDS accumulates. Edge cases are one of many reasons why working with a GDS-accredited partner changes the trajectory of a project. With accredited vendors, a client avoids paying extra money for errors and the long learning curve that’s inevitable for newbies. Besides that, the right architecture will be laid from the very beginning, so the quality will be better as well.
Certification takes its time, too
Before switching from simulated to live data, an integration must pass the GDS’s certification process, where the GDS specialists access your test environment to confirm that the entire travel-shopping flow behaves correctly end-to-end. This phase typically takes four to eight weeks and is worth factoring into any time-to-market plan.
How to speed up the integration
Business negotiations and certification bookend the integration process, and both depend entirely on GDS’s own timelines. What happens in between—development and testing, with the flow, scope, and data normalization challenges mentioned above—is where integration can be significantly accelerated.
How to accelerate an OTA/TMC integration with a GDS.
AI SDLC and spec-driven development
Cursor, Copilot, Claude Code, and similar tools enabled more rapid integration development, making coding itself less of a bottleneck. “We can already state that AI can develop on the same level as a human”, says Oleksandr Hryhor, Solution Architect at AltexSoft who works on AI engineering.
But large language models can do more than just generate code. In an AI-enabled software development lifecycle (SDLC), AI is used across every stage, from planning the product or feature to creating test cases and executing end-to-end testing. Humans shift from doing routine work to defining requirements, making architectural decisions, governing AI outputs, and approving the final result.
Just like the traditional SDLC, the AI SDLC begins with defining the project requirements, with all subsequent development built around them. A detailed, structured specification — describing user flows, system architecture, data models, edge cases, and acceptance criteria — serves as the primary input for AI coding agents. A clear spec gives the AI unambiguous context for generating correct code and makes the output easier to verify and regenerate. This approach is known as spec-driven development, as opposed to vibe-coding. i.e., coding by iterative prompting.
“We need to provide the LLM with the correct context: all the connections, necessary information about edge cases and exceptions, so the task is done within specific boundaries, rather than the AI just inventing and implementing arbitrary functionality,” says Olexandr.
The specification itself can be written either by a human developer or by an LLM — it depends on the context and the client’s preferences, since the client decides how to balance human oversight against speed of delivery.
Knowledge graphs
Either way, whoever is writing the specification—a human developer or an LLM agent— needs a solid understanding of how the OTM/TMC platform is built. To support this, the engineering team can create a knowledge graph—a structured representation of the system, including its components, business logic, and the relationships between them.
For example, we use Interlace—our in-house knowledge graph platform, that scans the client’s existing codebase and documentation and unifies them into a single live system map. In this map, every function sits in context: which user flow it belongs to, what it depends on, and what could break if it changes.
How AltexSoft’s in-hose knowledge graph helps accelerate GDS integration
A knowledge graph is exposed via Model Context Protocol (MCP), so AI agents can query it directly through an MCP server instead of searching raw files.
For a task like implementing flight booking, the agent works from the filtered slice of the graph relevant to that flow, plus the “blast radius”—which other modules the change might affect. This way, Interlace makes it possible to build a more precise specification for each feature in the integration process, without missing important dependencies.
The same graph also serves as a shared source of truth across team boundaries: in a multi-microservice platform where different teams own different repositories, it consolidates services, APIs, and dependencies into one connected map that can be updated by AI agent as code changes, making the impact of a given change visible to every team touching related components—which reduces the coordination overhead and merge conflicts that come from large, overlapping pull requests.
Edge cases knowledge base
A significant portion of the integration effort is spent testing, troubleshooting, consulting documentation, and working with support teams. Building a shared knowledge base of edge cases and integration-specific behavior reduces this overhead and helps teams complete integrations faster. Moreover, this knowledge base can be universal, as all three major GDSs—Amadeus, Travelport, and Sabre—follow very similar workflows and have common suppliers (airlines), which is why many integration edge cases are shared across providers.
Once an edge case or other integration-specific behavior is identified, it can be captured in the specification document, making them immediately available to both developers and AI agents.
Serhii Shkodenko expects the effect on a second integration rather than the first: “If we already had one integration, it would extract the workflows, all the required APIs, and all the peculiarities—and for the next integration those edge cases would be covered almost automatically”.
This is particularly relevant because most clients approach AltexSoft not for greenfield integrations, but for extending existing ones with new endpoints or migrating them to new technologies.
Business flow wrappers
Building a flow (booking, ticketing, etc) means chaining several API calls in sequence. What’s not always obvious up front is exactly how individual endpoints connect to form a working flow.
That understanding comes from experience: knowing what each endpoint expects, what it returns, and how the sequence fits together for a given task. Some of it only surfaces through direct engagement with a support team—the kind of specific, carrier-level detail (like a particular parameter value that only works for one airline) that isn’t written down anywhere publicly.
Once a flow (be it flight search, booking, cancellation, or ticketing) is understood well enough to describe precisely, it can be wrapped into a spec for an AI agent, so the agent knows the correct order of calls, the branching logic, and which endpoint to use for a given task.
Such flow wrappers enable a team to accelerate integration timelines by building on knowledge that would otherwise have to be rediscovered from scratch on every new project.
MCP on the GDS side
Beyond flow wrappers, the same problem of fast and accurate API chaining can also be addressed through MCP — an open standard that lets AI agents discover and call external tools in a uniform way, instead of needing custom integration code for every API. Applied on the GDS side, an MCP server gives an AI agent definitions for each call — expected parameters, expected fields, and error semantics — published directly as part of the tool definition. An agent can query what a given API call accepts and get an answer on the spot, and use that to reason through the sequence of calls a flow requires.
And this isn’t theoretical. Today, two major GDS are already moving this way.
Sabre MCP server. Source: Sabre developer portal
In 2025, Sabre launched its own proprietary MCP server, built into SabreMosaic and only available for Sabre’s existing partners and customers so far. Sabre’s MCP layer exposes APIs for AI agentic booking — search, selection, and booking confirmation (with a recent field trial that also allows extended servicing of flights). That’s the use case the GDS provider pushed into production first; however, we’re confident the GDS team is already working to expand MCP capabilities to enable more flows and make use of MCP for standard API integration purposes, as agents can explore flows via MCP.
Travelport partnered with Cognizant and Anthropic to put an MCP layer on top of Trip Services, its platform for handling bookings, exchanges, and refunds. As for August 2026, Travelport’s MCP layer exposes both booking and post-sale servicing, but only via Orchestra (Travelsoft Group’s Transport Hub), giving the 400+ European travel agencies already connected to Orchestra access to Travelport’s airline content. The GDS plans to extend the same integration to its other platforms — airQuest, Atcore, Tigerbay, Traffics, and Travel Connection Technology.
What to consider when using AI for integration—and where to watch carefully
Speed only matters if the result is something a company can actually trust in production. For this, AI (so far?) needs a human standing next to it.
Keep a human in the loop
There are at least two reasons you shouldn’t entrust the integration process entirely to AI.
Without the context management and review processes, LLM usage can scale rapidly. Every interaction with an LLM consumes tokens, and AI agents left to fend for themselves can end up processing far more information than is actually needed to complete a task. Human oversight not only improves quality but also helps control token consumption and infrastructure costs.
Some organizations have already discovered that replacing developers with AI is not as economical as expected. As Oleksandr Hryhor notes, “The goal is to involve both AI and humans in the process without making it more expensive than hiring a developer.”
AI needs guardrails when it comes to business logic and clients’ money. In sensitive parts of the system, AI needs precise instructions and automated evaluation built around it; it can’t be left to guess.
“AI should not be given responsibility for fare accuracy, payments, or automated ticketing, as mistakes are expensive”, warns Fritz Oberhummer. “We have seen examples of large airlines letting chatbots do whatever they wanted, resulting in unauthorized rebookings and free discounts.”
According to Fritz, putting guardrails on AI allows you to ship faster and better later on; without them, you might save time at the start, but eventually, immature AI will cost you money and become a major risk to your company. Making sure that methods are properly captured via reusable AI skills and reinforced through repeated LLM evaluations significantly reduces the risk of AI models going rogue.
“We have to be cautious with booking, ticketing, and all these things because it’s clients’ real money,” Serhii agrees. “Say, testing on production should be overseen by a human. We need to catch the moment when, in a one-in-a-million case, the LLM decides it needs to book a thousand flights to cover all the cases. We don’t know whether it will remember to void all these test tickets after the test is finished.”
Maintain compliance
Data privacy and compliance are among the most common concerns when introducing AI into software development and integration workflows. To address these concerns, Interlace supports multiple deployment models.
Organizations with strict security requirements can deploy the platform within their own infrastructure using an on-premises or private-cloud setup, ensuring that data remains within their security perimeter. For companies that want to use foundation models without sending data directly to providers such as OpenAI or Anthropic, Interlace can also connect through AWS Bedrock.
In addition, data stored by the platform is encrypted, retention policies can be configured to meet client requirements, and customer data can be removed from the system when requested. In many respects, this follows the same security model that organizations already use when adopting AI-assisted development tools.
Choose the right LLM for the job
Not all large language models perform equally well across every task involved in software integration. While it may be tempting to default to the most advanced model available, experienced teams typically focus on finding the right balance between quality, speed, and cost.
According to Oleksandr Hryhor, different models excel at different parts of the workflow. For example, Anthropic’s models have shown particularly strong performance in building and analyzing knowledge graphs, while OpenAI’s models may be a better fit for tasks such as generating embeddings or handling high-volume workloads, because they are cheaper. The key is flexibility. “Say, if a client from the Middle East prefers DeepSeek or another Chinese model, we can create a connector pretty quickly. So it’s not a problem”, assures Olexandr.
In practice, many teams find that mid-tier models like Claude Sonnet 5 or GPT-4 offer the best return on investment, delivering strong results at a fraction of the cost of frontier models.
“Building a scalable foundation with Knowledge Graphs, Skills, Agents.md’s, and other tools—and continuously evaluating it across different AI models—allows businesses to stay flexible about which models they use,” Fritz remarks. “After all, AI should not add even more complexity, but enable a fully automated, end-to-end traveler journey.”
