You ever have that experience where you are looking for a very specific flight, maybe a multi city trip with a couple of layovers, and you find it on one site, but then you go to book it and suddenly it is gone? Or you try to find the same route on a different app and it says no results found, even though you know those planes are flying? It feels like the digital equivalent of a ghost hunt. You are staring at a search bar that looks so simple, just a departure city and a destination, but behind that white box is one of the most fractured, legacy heavy, and frankly, nightmare inducing distributed systems in the entire world of technology. It is the spinning wheel of death, but for your vacation plans.
It really is a house of cards held together by duct tape and nineteen eighties era protocols, Corn. Herman Poppleberry here, by the way. And you are right, that frustration of the disappearing ticket or the missing route is not just a glitch in the app you are using. It is a symptom of a massive technical debt that the travel industry has been carrying for decades. Our housemate Daniel actually sent us a prompt about this earlier today, asking why it is so hard to build reliable travel tech tools in an era where we can basically do everything else instantly. He was looking into the data stack for flight information, and it turns out, once you pull back the curtain, it is not just data. It is politics, legacy hardware, and a very deliberate kind of content fragmentation. We are talking about systems that were designed when the primary way to communicate was a teletype machine.
It is funny because as a user, you assume there is just one big database of every flight in the sky. Like, surely the Federal Aviation Administration or some international body has a master list, right? But as we are going to explore today, that is a complete illusion. There is no single definitive source for every seat on every plane. Instead, you have these massive, ancient systems fighting with new modern standards, and the poor developers caught in the middle are just trying to make sure the price you see is the price you actually pay. It is a world where a single bit flip in a mainframe in Oklahoma can make a flight to Tokyo vanish from every travel site on earth.
And to understand why your travel app is failing you, or why it is so hard to build a new one, we have to talk about the G-D-S. The Global Distribution Systems. These are the three titans of the industry: Amadeus, Sabre, and Travelport. If you look at the history, these systems were basically the first ever large scale e-commerce platforms. Sabre, for example, grew out of a collaboration between I-B-M and American Airlines way back in the nineteen fifties and sixties. We are talking about mainframe technology that predates the modern internet by decades. They used a system called T-P-F, or Transaction Processing Facility, which was designed to handle thousands of transactions per second with almost zero latency, which was incredible for the time, but it was built in an era of extreme constraints.
And that is the crazy part, Herman. These systems are still the backbone. If you go to a travel agent, even today, they are likely tapping into one of those three. But they are not using a nice, clean R-E-S-T A-P-I with J-S-O-N responses. At least, they did not start that way. They were built on a messaging standard called E-D-I-F-A-C-T. That stands for Electronic Data Interchange for Administration, Commerce and Transport. It is a standard that was developed by the United Nations, of all things.
Oh, E-D-I-F-A-C-T is a trip, Corn. If you have ever looked at a raw E-D-I-F-A-C-T message, it looks like someone fell asleep on a typewriter. It is incredibly dense, cryptic, and meant to save every single byte of data because back when it was designed, bandwidth was expensive. It uses segments and delimiters that are just totally alien to a modern web developer. You will see things like U-N-B plus I-A-T-A, followed by a string of numbers and apostrophes. It is not human readable in the slightest. And yet, for a huge chunk of the world’s flight inventory, that is still the native language. When you book a seat, there is often an E-D-I-F-A-C-T message flying across a private network like S-I-T-A to a mainframe somewhere in Texas or Germany.
So, when a developer today wants to build a travel tool, they are essentially trying to put a modern face on a system that was designed before the mouse was even a common peripheral. It is like trying to build a high speed racing car but the engine is a steam locomotive hidden inside a box. But there has been a shift lately, right? This N-D-C standard we keep hearing about. New Distribution Capability. Is that finally the silver bullet that brings travel tech into the twenty first century?
That was the promise, but the reality is much more complicated. N-D-C was an initiative led by I-A-T-A, the International Air Transport Association. The goal was to move away from those old E-D-I-F-A-C-T standards and toward modern X-M-L and J-S-O-N based A-P-Is. The idea was that airlines wanted more control. In the old G-D-S model, a flight is just a commodity. It is a seat, a price, and a schedule. But airlines want to sell you more. They want to sell you extra legroom, pre paid meals, Wi-Fi packages, and lounge access. These are called ancillaries. The old systems could not handle that kind of rich data very well because the message formats were too rigid.
So N-D-C was meant to allow airlines to talk directly to the booking platforms, bypassing the middleman of the G-D-S? It sounds like a classic case of disintermediation.
That was the original fear of the G-D-S companies. They thought N-D-C would kill them. But what actually happened is quite fascinating from a market perspective. Instead of being bypassed, the G-D-S players like Amadeus and Sabre pivoted. They became N-D-C aggregators themselves. So now, instead of just providing their own legacy data, they provide a layer that connects to the airlines' N-D-C A-P-Is. It is a bit like how we talked about the hidden hierarchy of the cloud back in episode seven hundred ninety seven. You think you are going direct, but there is still a massive wholesaler in the middle. And this has created what I call the Dual Track A-P-I Tax.
The Dual Track A-P-I Tax. I remember we touched on that in episode twelve zero nine. For a developer, that means you have to maintain two completely different integration paths, right? One for the old school G-D-S content and one for the new N-D-C content.
And they do not behave the same way. The legacy G-D-S systems are often stateful. You open a session, you search, you hold a seat, and then you book. If the connection drops, the session might hang. N-D-C is supposed to be more stateless and modern, but because it is often just a wrapper around the airline's own internal legacy systems, it can be incredibly buggy. You might get a successful search result from an N-D-C A-P-I, but when you go to book, it fails because the airline's internal database hasn't synced with the A-P-I layer. It is a mess.
It feels like every time we try to simplify these stacks, we just add another layer of abstraction. And that brings up a huge point for developers. If I am building a travel app today, where do I actually get my data? Do I go straight to the G-D-S, or do I use one of these newer aggregators like Skyscanner or Kiwi or Duffel?
That is the million dollar question, and the answer depends on how much pain you are willing to endure. If you go with a G-D-S A-P-I, like Amadeus for Developers, you are getting the closest thing to the source of truth for the legacy carriers. You get the best ability to handle what we call interlining. This is a crucial concept that people often overlook. Interlining is when you have a trip that involves two different airlines that have a formal agreement to handle each other’s passengers. If you book a flight from Jerusalem to some small town in the American Midwest, you might fly El Al to New York and then United the rest of the way.
Right, because interlining is not just about the flight. It is about the baggage transfer, the liability if one flight is delayed, and the shared ticketing. That is a massive amount of back end logic. If my El Al flight is late and I miss my United connection, who is responsible for rebooking me? The G-D-S handles all of those legal and technical contracts through something called the Multilateral Interline Traffic Agreement, or M-I-T-A.
Precisely. And that is why the G-D-S is so hard to replace. An N-D-C connection is usually just between one airline and one platform. It is great for booking a direct flight on Lufthansa, but it is terrible at coordinating a complex trip across three different airline alliances. The G-D-S is the only system that truly understands the complex web of interline agreements that make global travel possible. But I have seen a lot of developers get frustrated with those G-D-S A-P-Is because they are still very complex. They have these concepts of P-N-Rs, or Passenger Name Records. A P-N-R is basically a big text blob that contains everything about your trip. It is not a clean database object; it is a legacy record format that you have to parse very carefully.
So if you are a startup and you do not want to deal with the headache of P-N-Rs and E-D-I-F-A-C-T, you go to an aggregator. You use something like Kiwi dot com and their Tequila A-P-I or Skyscanner. These aggregators basically scrape or license data from hundreds of sources, including G-D-S, direct airline A-P-Is, and even other aggregators. They give you a much cleaner, more modern A-P-I. But here is the catch, and this is where the user experience starts to break: the caching.
Oh, the caching trap. We have touched on this before in the context of database explosion, but in travel, it seems even more critical. If you are an aggregator, you cannot afford to query every single airline in real time for every single search. That would take minutes. It would also kill the airline's servers. Airlines actually monitor what they call the Look to Book ratio. If you search a thousand times for every one booking you make, the airline might cut off your access because you are costing them too much in computational overhead.
So the aggregators cache the results to keep the Look to Book ratio healthy and the speed high. You search for a flight, the aggregator looks in its database and says, "Yep, we saw that flight for four hundred dollars ten minutes ago." But in those ten minutes, three people booked the last seats at that price, or the airline’s dynamic pricing algorithm kicked in and bumped it to five hundred. So you click "book," the aggregator finally reaches out to the actual airline system, and suddenly it gets a "price changed" or "seat unavailable" error. This is why AI travel agents are struggling so much right now. They are making plans based on stale data.
It really does. And we cannot talk about flight data without addressing the biggest myth in the industry. I cannot tell you how many times I have seen developers on forums asking, "Where is the Google Flights A-P-I?" They see how fast and accurate Google Flights is, and they assume there must be a public A-P-I they can just pay to use. They think, "If Google can do it, I should be able to hook into their feed."
And the reality is?
The reality is that there is no public Google Flights A-P-I. Google bought a company called I-T-A Software back in two thousand eleven for seven hundred million dollars. I-T-A was the genius behind the Q-P-X search engine, which was the gold standard for finding complex routes. For a while, you could actually license a limited version of that A-P-I, called Q-P-X Express. But Google shut that down in April of twenty eighteen. They took that technology, integrated it into their own search results, and basically shut the door. They have a very limited enterprise version for massive partners like major airlines or massive travel agencies, but for your average developer or even a mid sized startup, Google Flights is a walled garden. You cannot use their data to build your own tool.
That is such a huge hurdle because Google has essentially set the expectation for what search should look like. Fast, comprehensive, and accurate. They have the massive compute power to run those complex routing algorithms in real time. But if you are a developer, you are forced to use these third party aggregators that are inherently slower and less accurate because they do not have the direct, deep integration that Google has with the I-T-A backend. It creates this massive gap between what the big players can do and what an innovator can do. It is almost like Google has a monopoly on the "fast path" of flight search.
It really does, and it leads to what I call the Dark Inventory problem. Even if you have a G-D-S connection and a couple of aggregators, you are still not seeing the whole picture. There is a massive amount of flight data that is effectively invisible to traditional systems. The most obvious example is Low Cost Carriers, or L-C-Cs. Think of airlines like Ryanair in Europe or Southwest in the United States. These airlines often refuse to play by the G-D-S rules.
Right, Southwest is famous for this. You cannot find their flights on Expedia or Orbitz. You have to go to Southwest dot com. This is a deliberate business strategy, right?
They refuse to pay the distribution fees to the G-D-S, which can be anywhere from five to fifteen dollars per segment. They want to own the customer relationship and keep their costs down. So if you are building a "comprehensive" travel tool and you do not have a direct integration with Southwest’s private A-P-I, your users are missing out on some of the cheapest flights available. And building those direct integrations is a nightmare. Each airline has its own quirks, its own authentication methods, and its own data formats. Some of them don't even have A-P-Is; they require you to use screen scraping, which is incredibly brittle.
Screen scraping in twenty twenty six? That sounds like a recipe for disaster. One small change to the airline's website layout and your entire data feed breaks.
It happens all the time. There have been massive legal battles over this. Ryanair, for example, has spent years suing aggregators and "screen scrapers" for accessing their data without permission. They argue it is a violation of their terms of service and that it leads to "hidden markups" for consumers. But from the developer's perspective, if you want to show your user the best price, you have to find a way to get that Ryanair data. So you have this fragmentation where the budget airlines are over here in their own silos, the legacy carriers are over there behind the G-D-S wall, and then you have this new N-D-C content which is creating even more fragmentation.
I read that some airlines are now withholding their best fares from the G-D-S entirely. They are making them "N-D-C exclusive." This seems like a way to force the industry to move to their new standards, but it’s really hurting the transparency of the market.
That is exactly what is happening. American Airlines made a huge push recently to move more of their content into N-D-C channels. They are basically saying to the travel agents, "If you want our best prices and our full range of services, you have to use our N-D-C connection." This has caused a massive uproar in the corporate travel world. Imagine you are a travel manager for a big company. For twenty years, you have used one portal, like Concur, to book everything. Now, suddenly, you realize that half the flights your employees need are not in that portal anymore, or they are twenty percent more expensive than what they see on the airline’s website.
It sounds like a regulatory nightmare. Is there an argument to be made that this is anti competitive? If an airline has a dominant position and they are withholding inventory from the traditional channels to force people into their own systems, does that violate any laws?
It is a very hot topic. The U-S Department of Transportation has been looking into this. In twenty twenty four, they issued a ruling requiring airlines to be more transparent about fees for baggage and cancellations, but the issue of "content withholding" is more complex. From the airline’s perspective, they are just trying to modernize their retail experience. They argue that the G-D-S companies have had a monopoly on distribution for too long and have stifled innovation. They want the freedom to offer personalized pricing. For example, if they know you are a frequent flyer, they might want to offer you a bundle that includes a lounge pass. The old G-D-S systems just can't do that.
But from the perspective of the travel agents and the G-D-S, it looks like a way to circumvent price transparency. If a flight is not in the central system, it is much harder for a consumer to compare it against other options. It is the same tension we see in almost every tech vertical right now. The move from open or centralized standards toward proprietary, vertically integrated stacks. But in travel, the stakes are so high because it is a global utility. And for the developer, it just means more work. Now you do not just need a G-D-S A-P-I, you need a specialized N-D-C aggregator too.
And you have to deal with the technical debt of those N-D-C A-P-Is themselves. Even though they are "modern," they are often just wrappers around older logic. I have heard developers complain that an airline's N-D-C A-P-I will return a successful search result, but then fail at the booking stage because of some internal legacy check that the A-P-I did not account for. It is what we called the "Dual Track A-P-I Tax" in episode twelve zero nine. You are maintaining two different ways to do the exact same thing, and neither one is perfect. One is a forty year old mainframe and the other is a buggy X-M-L wrapper around that same mainframe.
So, if we look at this from the perspective of someone trying to build a next generation travel tool, maybe something powered by these new AI agents we keep talking about, how do you even begin to normalize this data? If you have one feed coming in via E-D-I-F-A-C-T from Amadeus, another coming via an N-D-C X-M-L feed from United, and a third being scraped from a budget airline's website, how do you make sense of that in a way that an AI can actually reason about it? An AI needs a clean, consistent world model. It can't handle "sometimes this field is a string, sometimes it's a nested object, and sometimes it's just missing."
That is where the architectural shift toward things like GraphQL and the Model Context Protocol, or M-C-P, becomes really interesting. We just did an episode on this, episode twelve twenty, about A-P-Is for agents. If you are a developer, you almost have to build a normalization layer. You need a middle tier that takes all those messy, fragmented sources and turns them into a single, clean schema. You need to be able to say, "Give me all flights from Tel Aviv to London," and have your middle tier handle the logic of checking the G-D-S, checking the N-D-C feeds, and checking the L-C-C scrapers. You are essentially building your own private version of I-T-A Software.
But that middle tier is incredibly hard to maintain. Every time an airline changes its A-P-I or a G-D-S updates its schema, your normalization layer breaks. It feels like a never ending game of whack a mole. And you have to deal with the "Offer and Order" logic of N-D-C, which is totally different from the "Search and Book" logic of the G-D-S.
It is. Which is why you see companies like Duffel or Gordian Software becoming so popular. They are essentially selling "normalization as a service." They do the hard work of maintaining all those direct connections so that you, the developer, can just use one clean A-P-I. They handle the P-N-Rs, they handle the E-D-I-F-A-C-T, and they handle the N-D-C versioning—because yes, there are different versions of N-D-C, like seventeen point two and twenty one point three, and they are not always backward compatible. But even then, you are adding another middleman, another layer of latency, and another point of failure.
And let’s talk about that latency for a second. In the world of AI agents, latency is the enemy. If an agent has to wait thirty seconds for a flight search to complete because it is hitting five different fragmented sources, the user is going to give up. We are used to the Google search speed of milliseconds. But the reality of a live, un-cached flight search is that it takes time for those packets to travel to a mainframe, get processed, and come back. If an AI agent is trying to optimize a complex itinerary across three different meetings in three different cities, it might need to run hundreds of search queries in the background.
This is why I think the "Agent First" shift is going to force a reckoning in the travel industry. For a long time, the industry has relied on the fact that humans are patient. We are willing to wait for a progress bar to crawl across the screen if it means finding a cheap flight. But an AI agent is a high frequency consumer of data. If the A-P-I takes five seconds to respond, and the agent needs to make twenty calls to find the best route, that’s a hundred seconds of waiting. The current infrastructure simply cannot handle that kind of volume and speed. We are going to need a "High Frequency Trading" equivalent for travel data.
So what is the takeaway for our listeners who might be looking at this space? If you are thinking about building a travel tech startup or an AI travel assistant, what is the strategy? Do you just wait for the industry to fix itself, or is there a way to play the game as it exists today? Because it sounds like the "fix" is still years, if not decades, away.
My advice would be: do not try to compete on "breadth" unless you have a massive amount of capital and a huge engineering team. If you try to build a "better Expedia," you are going to lose to the incumbents who have already spent billions on these legacy integrations. Instead, you have to find a niche where the fragmentation is actually your friend. You have to find a place where the "Dark Inventory" is the most valuable part of the equation.
Like what? Give me an example of a niche that works in this fragmented world.
Well, for example, focusing on a specific type of travel that the big players ignore. Maybe it is ultra complex interlining that requires a specialized knowledge of certain regional carriers in Southeast Asia or Africa. Or maybe it is a tool specifically for corporate travel managers that helps them navigate the N-D-C gap by providing better visibility into those "exclusive" fares that their current tools are missing. You have to provide value that comes from navigating the complexity, rather than just trying to hide it. You are the guide through the digital ghost hunt.
I also think there is a huge opportunity in the "verification" space. If you can build a tool that can instantly verify if a cached price is actually available, that is a huge win for AI agents. Imagine an A-P-I that doesn't just give you search results, but gives you a "confidence score" for each result based on how recently it was verified and the historical reliability of that specific carrier’s data feed. An agent could then prioritize the "high confidence" flights even if they are slightly more expensive, because the risk of a booking failure is lower.
That would be a game changer. It is basically adding a meta data layer on top of the fragmented mess. And it brings us back to the importance of specificity. We always talk about how "data is the new oil," but in travel, "accurate, real time data is the only oil that matters." Everything else is just sludge that gums up your system. You need to know not just that a flight exists, but that the seat is actually there and the price is final.
It is also worth considering the geopolitics of this. We are sitting here in Jerusalem, and we see how regional conflicts or policy changes can instantly affect flight data. When a country closes its airspace, or an airline cancels all flights to a certain region, that information has to propagate through all those layers we just discussed. If you are relying on an aggregator that caches data for four hours, you might be selling tickets to a flight that was cancelled three hours ago because of a geopolitical event. The "latency of truth" can have real world consequences.
That is a great point, Corn. And it is something we see quite often here. The reliability of the "source of truth" is not just a technical issue, it is a safety and operational issue. In a world that is increasingly volatile, the ability to have a direct, low latency connection to the airline’s actual operational database is more valuable than ever. This is where the conservative worldview of prioritizing national security and robust infrastructure really intersects with tech. You cannot have a functioning travel economy if your data distribution is a black box that no one can trust. You need resilience.
It comes down to transparency and accountability. If an airline is withholding data or using legacy systems to hide pricing fluctuations, they are ultimately hurting the consumer and the broader economy. We need systems that are as robust and transparent as the American and Israeli markets they serve. We need a "Flight Data Bill of Rights" that ensures that if a seat is for sale, it must be visible to all authorized search tools in real time.
I agree. And I think we are going to see a lot of pressure from the U-S Department of Transportation and other regulatory bodies to ensure that N-D-C and other new standards are used to increase competition, not decrease it. There was a lot of talk during the last administration about "junk fees" and price transparency in the airline industry, and I expect that to continue regardless of who is in power because it is such a universal pain point for voters. Everyone hates the "disappearing flight" trick.
So, to wrap this up, the travel tech landscape is essentially a battlefield between forty year old mainframes and modern AI ambitions. The G-D-S is not dead; it is just evolving into a very expensive middleman for N-D-C content. Google Flights is a brilliant tool that you, as a developer, will likely never be allowed to use. And the dream of the autonomous AI travel agent is currently being held back by stale caches and fragmented budget airline data. It is a tough road, but for those who can bridge the gap, the rewards are massive.
That is a pretty accurate summary. It is a tough space to build in, but for the right developer with a deep understanding of these protocols, it is also a space where you can create immense value. If you can solve the "trust" problem in travel data, you have solved the biggest hurdle to the next generation of travel. You are basically building the nervous system for the global economy.
Well, I for one am going to be a lot more patient the next time my travel app tells me a flight is "no longer available." I will just imagine a lonely E-D-I-F-A-C-T message somewhere in a Texas basement, trying its best to tell me that the last seat just got sold to someone else three seconds ago. It is a miracle it works at all, honestly.
Just a bunch of bits and bytes flying through a green screen terminal. It is almost poetic, in a very frustrating sort of way. We are still living in the world that I-B-M and American Airlines built in nineteen sixty. We just have prettier screens now.
If you are interested in diving deeper into the technical side of this, I highly recommend checking out episode twelve twenty. We go into a lot more detail about how GraphQL and the Model Context Protocol can help manage these kinds of fragmented A-P-I ecosystems. It is a great companion to today’s discussion, especially if you are actually writing code.
And if you want to hear more about the "Agent First" shift and why we think it is the biggest thing to happen to software since the cloud, episode twelve zero nine is the place to go. We really dig into why building for AI agents requires a completely different mindset than building for humans. You have to optimize for different things—speed and accuracy over UI and UX.
We have covered a lot of ground today, and I hope this gives some clarity to anyone who has ever looked at a flight search results page and wondered, "How hard can this really be?" The answer, as it turns out, is "extremely." It is the final boss of A-P-I integration.
Beyond extremely. It is a world of legacy protocols, political infighting, and hidden data. But that is what makes it "My Weird Prompts" material.
Well, thank you all for joining us for another deep dive. If you are enjoying these explorations into the guts of the modern tech stack, we would really appreciate it if you could leave us a review on your podcast app or on Spotify. It genuinely helps other people find the show and keeps us motivated to keep digging into these rabbit holes.
Yeah, it really does make a difference. And if you want to stay up to date with everything we are doing, head over to myweirdprompts dot com. You can find our full archive there, plus our R-S-S feed and all the different ways to subscribe. We are also on Telegram—just search for My Weird Prompts to get a notification every time a new episode drops.
Thanks again to Daniel for sending in this prompt. It was a fun one to tackle. We will be back next time with another deep dive into the weird and wonderful world of technology, politics, and everything in between.
Until next time, this has been My Weird Prompts. I am Herman Poppleberry.
And I am Corn. We will see you in the next one.
