EDI vs. API: which integration a B2B supplier actually needs
For most established B2B suppliers the answer is both, in sequence. EDI is what large customers require, so if a trading partner mandates it you implement EDI because the contract says so, not because it is the better technology. An API is what you build for everything else: real-time order status, a customer portal, live pricing, your own integrations. Treating them as competing options is the mistake. EDI is a compliance requirement, an API is a capability.
This comparison usually arrives in one of two ways. Either a large customer has sent a supplier onboarding packet with an EDI requirement in it, or someone internal has asked why customers cannot check their own order status on the website. Those are different problems, and they have different answers, which is why the question keeps getting argued in circles.
The confusion is understandable, because both are described as ways for two systems to exchange data. But EDI is a set of standardised business documents with decades of trading-partner convention around them, and an API is a general-purpose interface for one system to ask another system a question. The first is a format your customer dictates. The second is a door you decide to build.
What follows is the practical version: what each one actually is, what each costs in effort rather than licence fees, and how to sequence them if the honest answer is that you need both.
Key takeaways
- EDI is rarely a choice. If a large customer mandates it, the decision has been made for you and the only question is how you implement it.
- An API is what makes anything customer-facing possible. Order status in a customer portal, live pricing, or a quote path all run on an API, and EDI cannot provide any of them.
- The cost shapes differ more than the prices. EDI costs are per trading partner and largely recurring; API costs are mostly a one-off build with ongoing maintenance.
- Batch versus real time is the difference your customers feel. EDI documents typically move on a schedule; an API answers now.
- Doing EDI does not mean you have an integration. A mapped EDI connection to one customer says nothing about whether your own systems can talk to each other.
At a glance
Why this is usually not a choice at all
The framing of EDI against API suggests two options on a table. In practice the sequence is almost always decided by somebody else.
A distributor or manufacturer wins a large account. The customer's supplier packet requires EDI, often naming specific document types and a transport method. There is no evaluation to run, because the alternative is not winning the account. Meanwhile the same company has customers asking whether they can see order status without phoning, which EDI cannot answer, and that is an API problem.
So the useful question is not which one is better. It is which one is being forced on you right now, and what you build once rather than twice.
What EDI is, and why it has outlasted every prediction of its death
EDI is a set of standardised documents. In North America that usually means ANSI X12 transaction sets: an 850 is a purchase order, an 855 acknowledges it, an 856 is an advance ship notice, an 810 is an invoice. Europe more often uses UN/EDIFACT. The documents move between trading partners either through a value-added network or directly over AS2, a transport specification published as RFC 4130.
It persists for an unglamorous reason: it works, and the cost of changing it falls on thousands of suppliers rather than on the large buyers who set the rule. A retailer or OEM with an EDI process refined over twenty years has no incentive to replace it, and every incentive to require it. Predictions that APIs would kill EDI have consistently underestimated that asymmetry.
The implication for a supplier is worth stating plainly. EDI competence is a commercial qualification, not a technical preference. If your segment sells into large buyers, being unable to do EDI removes you from consideration before anyone looks at your capabilities.
What an API gives you that EDI cannot
An API answers a question at the moment it is asked. That single property is what everything customer-facing depends on.
If you want a customer to log in and see the status of their order, that page has to ask your system a question and get an answer while the page is loading. If you want to show live stock or contract pricing, same. If you want a quote request to create a record in your ERP rather than an email in somebody's inbox, same again. None of that is achievable with scheduled document exchange, no matter how well the EDI is implemented.
The second property is reach. An EDI connection serves one trading partner and has to be mapped again for the next one. An API, once built, serves your website, your portal, your mobile app, a partner integration and an internal tool without a new project each time. The first consumer is expensive and the fifth is nearly free.
- Customer-facing order and shipment status
- Live stock and customer-specific pricing
- Quote and RFQ submission into your own systems
- Product data flowing to your website and to marketplaces
- Internal automation between systems you already own
The cost shapes are different, not just the numbers
Comparing headline prices here misleads, because the two spend money in different directions.
EDI cost is dominated by per-partner work and recurring fees. Every new trading partner brings its own implementation guide, its own quirks in how it fills the standard fields, and its own testing cycle. Ten customers on EDI is not one project, it is closer to ten smaller ones. Networks and translation services usually charge on documents or connections, so the bill grows with trade rather than sitting still.
API cost is dominated by the first build. Getting your data out of an ERP in a usable shape is the hard part, and it is largely a one-off. After that the marginal cost of another consumer is small, and the recurring cost is hosting and maintenance rather than per-transaction fees.
The practical consequence: if you expect to add trading partners steadily, model EDI as an ongoing operating cost. If you expect to add customer-facing features steadily, model the API as an asset that gets cheaper per use.
How to sequence it when you need both
Most established suppliers land on both, and the order matters because doing it backwards means building the same thing twice.
The pattern that holds up is to treat your own systems as the centre and both EDI and the API as edges on it. Get your product, pricing, inventory and order data accessible through one internal interface first. Then the EDI translator reads from that interface, and so does your website, your portal and anything else. Suppliers who instead bolt EDI directly onto the ERP for one customer, then bolt a website integration onto it separately for another purpose, end up maintaining two versions of the same business logic that disagree with each other.
- Establish one internal source of truth for orders, stock and pricing, and make it reachable programmatically.
- Implement the EDI a mandating customer requires, reading from that source rather than from the ERP directly.
- Build the customer-facing surfaces on the same interface: order status, then pricing, then self-service.
- Add each new trading partner as a mapping exercise rather than a new integration.
- Monitor the acknowledgments. An unread 997 or 999 is the most common way an EDI problem stays invisible for a week.
The same purchase order, arriving two ways
A customer places an order for 400 units. Here is what happens in each case, and what your team can see while it is happening.
- The customer's ERP generates an 850 purchase order document.
- It is transmitted through a value-added network or directly over AS2 on the next scheduled run.
- Your translator picks it up, maps the fields to your own order structure, and hands it to your ERP.
- You return a 997 functional acknowledgment confirming the document was readable, then an 855 confirming the order itself.
- If a field is wrong, the document is rejected and the failure sits in an acknowledgment until someone reads it.
A structured order in your ERP, correct and complete, some time after it was placed. Nobody on either side saw it happen, and the customer cannot check on it without contacting you.
- The customer's system, or your own portal, posts the order to your endpoint.
- Your system validates it and responds immediately with an order identifier or a specific error.
- The order appears in your ERP through the same internal interface the EDI path uses.
- The customer queries the status endpoint whenever they want and gets the current state.
- A malformed request fails at the moment it is sent, with a message naming the field.
The same structured order, plus an identifier both parties can reference, plus the ability for the customer to answer their own status question at two in the morning without calling anyone.
Common questions
Is EDI obsolete?
No, and it has outlasted repeated predictions that it would be. It persists because the large buyers who mandate it have refined the process over decades and bear none of the cost of changing it, while thousands of suppliers bear all of it. If your customers require EDI, its technical age is irrelevant to you.
Can an API replace EDI?
Only if your trading partner agrees to it, which for a large buyer usually means no. Some modern buyers do offer an API alternative and it is worth asking, because the ongoing cost is lower. But an API cannot replace an EDI requirement unilaterally, since the requirement belongs to the customer's process rather than to yours.
How much does EDI cost?
It varies too much to quote a useful figure, and anyone giving you one without knowing your partner count is guessing. The structure is what to plan around: setup and mapping per trading partner, plus recurring network or document fees that scale with volume. Get quotes based on your actual expected partner list and document count rather than a per-month headline.
Do we need EDI to sell to large customers?
Often yes, in retail, automotive, aerospace, healthcare and government supply chains, where it appears in the supplier onboarding packet as a condition rather than a preference. In many industrial and distribution segments it is not required at all. The answer is specific to the customers you are pursuing, so read their supplier requirements before assuming either way.
What is AS2 and do we need it?
AS2 is a specification for transmitting business documents securely over the internet, published as RFC 4130, and it is one of the two common ways EDI moves. The alternative is a value-added network that handles transport for you. Which one you need is usually dictated by the trading partner, and a network is generally the lower-effort option for a supplier with a small number of connections.
Can our website use the same integration as our EDI?
It should, and this is the design decision that saves the most money later. If both read from one internal interface onto your order, stock and pricing data, then adding a customer portal or a new trading partner is an addition rather than a rebuild. Suppliers who wire EDI straight into the ERP for one customer and then wire the website in separately end up maintaining two versions of the same logic.
Sources
- X12, the North American EDI standards body x12.org
- RFC 4130, MIME-based secure peer-to-peer business data interchange (AS2) rfc-editor.org/rfc/rfc4130
- OpenAPI Specification spec.openapis.org/oas/latest.html