EDI

Electronic Data Interchange the original machine-to-machine business integration

EDI is the part of API history that humbles me, and I think it should humble the whole API industry. Electronic Data Interchange is the electronic interchange of business information using a standardized format — one company sending structured data to another electronically rather than on paper, with the two parties called trading partners. It is, quite literally, the original API: a technical basis for automated commercial conversations between two entities, encompassing the transmission, the message flow, the document format, and the software used to interpret it. EDI has been quietly running global commerce since before the internet existed, and the deeper I dug into it — really seriously, around 2020, when I set out to map it as part of expanding my API toolbox — the more I realized how small my API world actually was, and how early in this whole journey we still are. If SOAP is the father of the API, then EDI is the grandfather.

The scope of EDI is genuinely staggering, and it’s mostly invisible to people who live in the modern web API world. When I mapped out the major EDI standards, I was looking at the infrastructure that governs how data moves across the global supply chain, and it dwarfs anything in the REST API space. X12, developed by ASC X12, drives business processes across healthcare, insurance, transportation, finance, government, and supply chain. UN/EDIFACT is the international standard developed under the United Nations, with syntax rules and standard messages for multi-country, multi-industry exchange. SWIFT, formed in 1973, operates the worldwide financial messaging network that moves money between banks. HL7 governs the exchange of electronic health information. GS1 EDI handles orders, despatch advice, and invoices across retail supply chains. TRADACOMS launched in UK retail in 1982. And there’s more — Odette for European automotive, IATA Cargo-IMP for air cargo, SCRIPT for electronic prescriptions, Edig@s for gas dispatching. These are not historical curiosities. They are the live, operational backbone of commerce, automotive, healthcare, aerospace, finance, and government, processing volumes that make the public API economy look like a toddler.

The thing I want people to absorb is that EDI is API — they are the same impulse, separated by decades. EDI standards employ FTP, SFTP, FTPS, email, HTTP, and the AS1/AS2/AS4 protocols to move data between trading partners. They provide the technical details of structured data exchange between machines, automating commercial conversations so that purchasing, fulfillment, logistics, and invoicing happen without human intervention. That is exactly what a modern API does. The difference is not conceptual; it’s generational and stylistic. EDI emerged from a world of dedicated value-added networks, expensive integration, batch processing, and rigid standards maintained by industry consortia and governing bodies. Modern web APIs emerged from a world of HTTP, JSON, self-service, and developer accessibility. But the fundamental act — two systems exchanging structured business data according to an agreed format to automate commerce — is identical. We didn’t invent machine-to-machine commerce with REST. We inherited it from EDI and gave it a friendlier face.

The history matters because it reframes how new the API economy actually is, and it’s a corrective to a lot of API-industry hubris. We in the API world have a tendency to talk as if programmatic data exchange began around 2000 with Salesforce, eBay, and Amazon — and those companies were genuine pioneers of the modern web API. But businesses had been conducting automated electronic commerce for decades before that. EDI standards governed commerce before the internet was even around, and they continue to define how data moves today. When I looked at EDI seriously, the lesson wasn’t “look how primitive the old way was.” It was the opposite: look how mature, how vast, how entrenched, and how successful this layer is, and how much of the global economy still runs on it. The API economy isn’t a finished revolution — it’s a young technology trying to extend into territory that EDI has held for fifty years.

What’s most instructive is that EDI never went away, and that’s the part people get wrong. The instinct in the API community has long been to treat EDI as “legacy” — something to be replaced, modernized, swept aside by the cleaner, lighter web API approach. But EDI is still running everywhere, processing enormous volumes, because it works and because it’s deeply embedded in the trading relationships of entire industries. Walmart and Amazon run EDI with their suppliers. Ford and Volkswagen run it across their automotive supply chains. CMS and Cigna run it in healthcare. The Department of Defense and the Department of Commerce run it in government. Boeing and Airbus run it in aerospace. These aren’t companies that haven’t gotten around to modernizing — they’re operating mission-critical commerce on infrastructure that has been refined over decades and that they have no urgent reason to rip out. EDI is a powerful reminder that “legacy” often just means “load-bearing.” The systems we dismiss as old are frequently the systems holding up the economy.

The connection to modern API work is the road map I came away with, and it’s reshaped how I think about the future. If you want the road map for the API industry over the next thirty years, I wrote, take a look at the EDI space. The opportunity isn’t to replace EDI — it’s to modernize the layer of the economy that EDI governs, incentivizing the companies and consortia that run it to adopt HTTP and HTTP/2, to standardize on XML, JSON, Avro, and Protocol Buffers, to bring modern API practices to the most important data flows in global commerce. Healthcare is where I’ve seen the most movement: HL7’s FHIR specification is essentially the modernization of healthcare EDI into a RESTful, resource-oriented API standard, and the HHS and CMS rules mandating patient API access are forcing that modernization forward. FHIR is the template — taking a mature EDI domain and giving it a modern API expression without discarding the decades of domain knowledge baked into the standard. The same work is waiting to be done across automotive, aerospace, finance, and the rest of the EDI-governed economy.

The power-broker dimension is the political reality of EDI, and it’s where the modernization will succeed or stall. The EDI space is messy, specialized, and busy, with many agencies and governing bodies servicing it — the standards consortia, the certification authorities, the value-added network providers, the EDI brokers who handle discovery and integration between trading partners. These are the gatekeepers of the EDI economy, and any real modernization has to go through them. If we want to bring the world of EDI into a modern API future, we have to focus on these power brokers, make them aware of what modern APIs offer, and help them see why HTTP-based, openly-standardized data exchange represents the future of interoperability. This is not a technical problem — the technical translation from EDI to API is largely tractable. It’s an adoption and incentives problem, the same commons-and-coordination challenge that shows up everywhere in the API space, just at the scale of entire industries with billions of dollars of entrenched infrastructure.

Studying EDI changed my sense of my own work and the timeline we’re actually on. After a few days mapping the world of EDI, it became painfully clear how early in the API journey we are — that the way we move data around with modern APIs is in its infancy compared to the maturity and scope of EDI. That realization is both humbling and clarifying. It told me I’d be spending the rest of my career evangelizing APIs, because the work of helping the global economy standardize on open, modern, HTTP-based data exchange is a multi-decade project, not a finished one. And it connects directly to my through-line about AI agents: when people get excited about agents as some radical new thing, I point out that agents are just APIs, nothing has changed — and EDI is the proof that runs even deeper. We have been automating machine-to-machine commercial conversations for fifty years. The agent calling an API is the newest expression of the same impulse that produced X12 and EDIFACT and SWIFT. The names change, the protocols get lighter, the access gets more democratic, but the fundamental act of structured data exchange to automate commerce is one continuous story. EDI is where that story starts, and remembering that keeps the modern API economy honest about how much it inherited and how much it still has left to do.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

References

Guidance Details

Explore more

Discover APIs