EDI vs API: The Old and New of B2B Integration

If you spend any time around business-to-business integration, you will hear the same confident prediction on repeat: APIs are the future, EDI is legacy, and it is only a matter of time before the modern technology sweeps the old one away. It is a tidy story, and it is wrong. Electronic Data Interchange has been moving trillions of dollars of trade documents between companies for more than four decades, and it is not shrinking. Application Programming Interfaces have become the default way modern software talks to modern software, and they are not going away either. Both are growing at the same time, in the same supply chains, often between the same two trading partners. Understanding why is the difference between an integration strategy that fights the real world and one that works with it. Before we compare the two, it helps to place them inside the wider discipline they both belong to, which I cover in the enterprise system integration pillar.

The message up front: EDI and APIs are not competitors racing to replace each other. They are two different tools optimised for two different problems. EDI is optimised for standardised, high-volume, document-oriented trade between many partners. APIs are optimised for real-time, application-to-application interaction. The organisations that win at B2B integration stop asking "which one replaces the other" and start asking "which one fits this specific exchange." For the bigger picture of how all of this fits together, start with the enterprise system integration pillar.

1. Two generations of B2B integration

To understand why EDI and APIs coexist, you have to understand that they were born to solve problems separated by nearly thirty years of technology. EDI emerged in the 1970s and was formalised through the 1980s, in a world of mainframes, dial-up connections, expensive bandwidth and no internet as we know it. The problem it solved was enormous and specific: how do you let thousands of companies, each running completely different internal systems, exchange purchase orders, invoices and shipping notices in a form that every one of them can read without a human retyping anything? The answer was a rigidly standardised document format, agreed by industry committees, transmitted in batches over private networks.

APIs, in the modern web sense, came out of a completely different era. By the 2000s the internet was ubiquitous, bandwidth was cheap, and software was increasingly built from services that call each other over HTTP. The problem an API solves is not "how do two mainframes exchange a standardised invoice overnight" but "how does one application ask another application a question and get an immediate answer." That is a real-time, conversational, application-centric problem, and it produced a real-time, conversational, application-centric solution: lightweight requests and responses, usually carrying JSON, usually over the same HTTPS that runs the web.

This is why the "old versus new" framing misleads. EDI and APIs are not two attempts at the same problem where the newer one is simply better. They are two solutions to genuinely different problems that happen to overlap in the territory of business-to-business data exchange. When people say APIs will kill EDI, they are quietly assuming the two problems are the same problem. They are not. That mistaken assumption is the root of most bad B2B integration strategy I encounter.

2. EDI in brief

Electronic Data Interchange is the computer-to-computer exchange of business documents in a standardised electronic format between trading partners. The key word is standardised. An EDI purchase order is not a free-form message; it is a document that conforms to a published standard, so that a supplier's system knows exactly where to find the buyer, the ship-to address, each line item, the quantity and the price, without any human interpretation.

Two standards families dominate. In North America the ANSI X12 standard defines document types by number: an 850 is a purchase order, an 810 is an invoice, an 856 is an advance ship notice, a 997 is the functional acknowledgement that confirms receipt. Internationally, and especially in Europe and logistics, the UN/EDIFACT standard plays the same role with named messages such as ORDERS, INVOIC and DESADV. Whichever family you use, the principle is identical: a committee-agreed structure that every conforming partner can parse.

Just as important as the format is the transport. Traditional EDI moved over Value Added Networks, or VANs, which are private third-party networks that act like a postal service for trade documents, holding messages in electronic mailboxes until each partner collects them. Over the last two decades much EDI has shifted onto AS2, a secure protocol that sends EDI documents directly over the internet with encryption and signed receipts, and onto SFTP and other secure file transports. The document standard and the transport protocol are separate choices, which is a source of endless confusion for newcomers.

The defining characteristics of EDI are batch orientation, document orientation and heavy standardisation. Messages are typically gathered and exchanged in batches rather than one transaction at a time. The unit of exchange is a whole business document. And the format is rigidly standardised so that partners who have never spoken can still trade. If you want the deeper mechanics of standards, envelopes and acknowledgements, I cover them in the what is EDI explainer.

3. APIs in brief

An Application Programming Interface is a defined contract that lets one piece of software request data or an action from another. In the B2B integration context the API almost always means a web API: a set of endpoints exposed over HTTPS that accept requests and return responses, most commonly using the REST style with JSON payloads. Where EDI ships a whole standardised document, an API exposes granular operations. You do not send an entire order file; you make a request such as "create this order," "get the status of order 4471," or "check available inventory for this item," and you get an immediate, structured answer.

The defining characteristics of an API are almost the mirror image of EDI. APIs are real-time rather than batch: you make a request and you get a response in the same moment, measured in milliseconds, not overnight. They are application-centric rather than document-centric: the unit of exchange is an operation on a resource, not a trade document. And they are far less globally standardised than EDI. There is no committee that defines what fields a purchase order API must contain; each vendor designs its own API surface, which is both a strength and a weakness we will come back to.

The format is lightweight. JSON is human-readable, easy for developers to work with, and natively understood by web and mobile applications, which is exactly why APIs dominate anywhere software needs to interact quickly and flexibly. If you want the mechanics of how REST APIs are structured, what verbs and status codes mean, and how authentication works, I lay that out in the REST API explainer. And for a concrete example of how a modern ERP exposes its data this way, the Business Central APIs and integrations guide walks through a real platform.

4. Head to head

The clearest way to see the relationship is to put the two side by side. On the left, EDI: a batch of standardised documents travelling through a VAN or over AS2 between two companies whose internal systems never speak the same language directly. On the right, an API: a real-time request and response in JSON, flowing over HTTPS the instant an application needs an answer. The diagram below captures both flows.

The picture makes the trade-off visible. EDI accepts latency and rigidity in exchange for a single, universally agreed format that lets a company trade with thousands of partners on the same terms. An API accepts a lack of universal standardisation in exchange for immediacy and flexibility. Neither trade is strictly better; each is right for a different situation. The table below sets out the same comparison across the dimensions that actually drive integration decisions.

Read the onboarding row carefully, because it is the one most people get backwards. APIs feel easier to onboard, and for a single integration they usually are. But because every vendor designs its own API, onboarding a hundred partners over APIs can mean a hundred different integrations. EDI feels harder to onboard, and per partner it is, but because everyone speaks the same X12 or EDIFACT, that effort is largely repeatable. Standardisation trades a higher first cost for a lower marginal cost. That is precisely why EDI survives in industries with thousands of trading relationships.

5. Where EDI still rules

EDI is not surviving out of inertia or fear of change, whatever the modernisation consultants imply. It rules in specific industries because its exact characteristics match their exact needs. Three sectors show this clearly.

Retail and consumer goods. A large retailer trades with thousands of suppliers, and the flow of purchase orders, invoices, advance ship notices and acknowledgements is enormous and highly repetitive. The retailer cannot build and maintain a bespoke integration with every supplier, and it cannot ask each supplier to conform to a proprietary API. What it can do is mandate EDI, because the standard means any supplier, using any internal system, can comply the same way. Major retailers routinely require EDI as a condition of doing business, and that requirement is rational: one standard, thousands of partners, predictable documents.

Logistics and transportation. Freight, shipping and third-party logistics run on documents that cross company and national boundaries constantly: shipping notices, bills of lading, customs and status messages. EDIFACT in particular is deeply embedded in global logistics because it was designed for exactly this cross-border, multi-party, document-heavy world. The volume is high, the documents are standardised by international agreement, and the participants change constantly, which is the ideal profile for EDI.

Healthcare. In the United States, healthcare claims, eligibility checks and remittances run on mandated X12 transaction sets under HIPAA rules. When an entire industry is legally required to exchange specific standardised documents, EDI is not a legacy choice, it is the compliant one. The standardisation that feels rigid to a developer is precisely what a regulator wants: every claim in the same auditable format.

The honest caution: EDI has real costs that its advocates sometimes gloss over. Setup per partner is genuinely slow, mapping documents is fiddly specialist work, VAN fees add up, and the batch rhythm means you rarely have real-time visibility. These are real weaknesses. They just do not add up to obsolescence in the industries where standardisation and volume matter more than immediacy.

6. Where APIs win

APIs win decisively wherever the value is in immediacy, interactivity or flexibility. The moment a business process needs an answer now rather than tomorrow morning, EDI's batch rhythm becomes a liability and an API becomes the obvious choice.

Consider real-time inventory. When a customer on a website asks "is this in stock," nobody wants an answer based on last night's batch file. An API call to the supplier's inventory service returns the current number in milliseconds. The same is true of live order status: a buyer who wants to know where a shipment is right now needs a query and an immediate response, which is exactly what an API provides and exactly what traditional EDI does not. Payment authorisation, address validation, tax calculation, shipping-rate quotes, real-time pricing, all of these are interactive questions that demand an immediate answer, and all of them are API territory.

APIs also win wherever modern software ecosystems meet. Mobile apps, web front ends, cloud platforms and software-as-a-service products are all built to talk over web APIs natively. When you integrate a modern ERP such as Business Central, a CRM, an e-commerce platform or a payment gateway, the vendor gives you an API, not an EDI document set, because the API fits how that software is built and deployed. The flexibility to expose granular operations, add new endpoints, version them and evolve them quickly is a genuine advantage in fast-moving product ecosystems. For the broader definition of how these connections are engineered, the what is system integration explainer sets the foundations, and the Business Central integration guide shows a working example.

The catch, and it is a real one, is the flip side of that flexibility: the lack of a universal standard. Because every vendor designs its own API, there is no equivalent of "the 850 purchase order" that every partner already understands. Integrating with fifty suppliers over APIs can mean fifty distinct integrations, fifty sets of authentication, fifty payload shapes and fifty change cycles to track. For a handful of key partners that is fine. For a supply chain with thousands of relationships it becomes unmanageable, which is exactly the gap EDI's standardisation fills.

7. The hybrid reality

Here is what actually happens inside a mature organisation, and it is neither pure EDI nor pure API. The two run side by side, each handling the exchanges it is best at, frequently between the same two trading partners. A large manufacturer might receive purchase orders and send invoices to a big retailer over EDI, because that retailer mandates it and the volume justifies it, while simultaneously exposing a real-time inventory API that the same retailer's e-commerce platform calls to check stock before displaying a product as available. Same relationship, two integration styles, each doing the job it fits.

This hybrid is not a transitional state on the way to an all-API future. It is the stable, correct end state, because the underlying problems it serves are permanently different. Standardised, high-volume, document-oriented trade will keep flowing over EDI. Real-time, interactive, application-level exchange will keep flowing over APIs. A growing middle ground uses modern integration platforms that can speak both, translating an incoming EDI document into an internal API call, or wrapping a legacy EDI flow behind a modern API facade so newer systems never have to know EDI exists underneath.

There is also genuine convergence at the edges. Some organisations now exchange EDI-standard documents over API transports, sending an X12 or EDIFACT payload as the body of an HTTP request rather than through a VAN. And modern EDI-as-a-service providers increasingly offer API front ends over their EDI networks, so a developer works with a clean API while the provider handles the EDI mapping and VAN connectivity behind the scenes. The line between the two blurs at the transport layer even as the underlying reasons for each remain distinct. The document-standardisation problem and the real-time-interaction problem are both still there; the tooling just gets better at serving both.

8. How to choose or combine

Strip away the "old versus new" noise and the decision becomes a short set of practical questions about the specific exchange in front of you. I use roughly this sequence when advising on a B2B integration.

• Does the exchange need to be real-time? If a human or a process is waiting on an immediate answer, such as a stock check, an order status or a payment authorisation, that is an API. If the exchange can happen on a schedule, such as a daily batch of invoices, EDI or a batch API both work and other factors decide.
• How many partners, and who sets the terms? If you must integrate with many partners on equal terms, or a dominant partner mandates a format, standardisation wins and that usually means EDI. If you control both ends, or you are integrating a small number of modern platforms, an API is simpler.
• What does the partner already support? The cheapest integration is often the one your partner already speaks. A retailer that only accepts EDI decides the question for you. A SaaS vendor that only offers an API does the same.
• Is it a document or an operation? Whole business documents moving between organisations, purchase orders, invoices, ship notices, lean toward EDI. Granular operations and queries, "create this," "get that," "check the other," lean toward APIs.
• What is the regulatory context? In sectors with mandated transaction standards, such as US healthcare, the compliant format is not a preference, it is a requirement.

The insight worth keeping: never let a technology preference override the shape of the exchange. The right question is never "are we an EDI shop or an API shop." It is "what does this specific exchange need," asked exchange by exchange. Answer it that way and you will end up with a hybrid, and the hybrid will be correct.

In practice, the strongest B2B integration architectures treat EDI and APIs as two capabilities of one integration layer rather than as rival platforms owned by rival teams. A modern integration platform or middleware layer ingests EDI documents and API calls alike, maps them to a common internal model, and lets the business logic stay ignorant of which protocol delivered the data. That is the architecture I steer clients toward: not "migrate off EDI," and not "APIs everywhere," but one integration capability fluent in both, applied per exchange. It removes the false choice entirely and lets each protocol do what it is genuinely best at.

9. References

• ANSI ASC X12, the accredited standards committee that maintains the X12 EDI standard used across North American retail, healthcare and logistics (x12.org).
• UN/EDIFACT, the United Nations rules for Electronic Data Interchange for Administration, Commerce and Transport, maintained through UNECE (unece.org).
• RFC 4130, the IETF specification for AS2, the protocol for transporting EDI and other business data securely over the internet.
• US HIPAA administrative simplification rules mandating X12 transaction sets for healthcare claims, eligibility and remittance (cms.gov).
• Microsoft Learn documentation on Dynamics 365 Business Central APIs, illustrating a modern ERP's REST API surface for real-time integration (learn.microsoft.com).

Final thoughts

The prediction that APIs will kill EDI keeps failing because it misreads what each technology is for. EDI is not an old attempt at the API problem, and an API is not a modern attempt at the EDI problem. They solve two different problems that both live under the banner of business-to-business integration, and both problems are permanent. Standardised, high-volume, document-oriented trade between many partners is not going away, and neither is the need for real-time, interactive, application-level exchange. So both technologies keep growing, often inside the same company and the same trading relationship, each carrying the traffic it fits.

The practitioner's move is to stop treating this as a rivalry and start treating it as a toolbox. Decide per exchange. Use EDI where standardisation and volume across many partners matter most. Use APIs where immediacy and flexibility matter most. Build an integration layer fluent in both, so the choice is never all-or-nothing and never political. Do that, and the tired "which one wins" debate simply dissolves into a series of sensible, exchange-by-exchange engineering decisions, which is exactly where it belonged all along.

Related reading: Enterprise system integration explained, What is EDI, REST API explained, Business Central APIs and integrations, What is system integration.