The most common question we get on any B2B integration engagement in 2026 is: EDI or API? A decade ago the answer was 'API if you can, EDI if you must'. Today it's more nuanced — and getting it wrong costs six-figure re-implementations.
The core difference
EDI is a document standard. It says: this is what a purchase order looks like, this is what an invoice looks like, this is what a shipping notice looks like. It does not care how the document moves — AS2, SFTP, VAN, HTTPS, floppy disk, whatever.
APIs are a transport pattern. They say: hit this URL with this JSON and get that JSON back. They do not care what the document means — that's on you to define, per partner, per integration.
You can absolutely wrap EDI in an API (POST an X12 850 to a REST endpoint), and you can absolutely define an EDI-like standard on top of APIs (OpenAPI schemas describing purchase orders). The label doesn't matter. What matters is: who else already speaks this language?
When EDI still wins
**Retail supply chain.** Walmart, Target, Costco, Amazon Vendor Central — every major North American retailer has an EDI-first onboarding process. If you want to sell into one of them, you speak EDI or you don't sell.
**Healthcare payer/provider exchange.** HIPAA mandates the use of X12N transaction sets (837 claims, 835 payments, 270/271 eligibility). No API rebellion is going to overturn a federal regulation.
**Automotive OEM tier-one supply.** VDA in Germany, X12 in the US. Fifty years of tooling, none of it moving.
**Ocean freight and customs.** UN/EDIFACT is the lingua franca of every port, customs authority and container line. APIs exist on top but the underlying standard is EDI.
When APIs win
**Any greenfield SaaS-to-SaaS integration.** Two modern SaaS products exchanging data? APIs, JSON, webhooks. There is no scenario where introducing EDI makes sense between two 2020s-era SaaS products.
**Mobile-first commerce (Shopify, Stripe, Square).** Consumer commerce has moved off EDI at the small-merchant level. Enterprise commerce still uses it on the back-end, but the front door is APIs.
**Real-time inventory, pricing and personalisation.** EDI is batch-oriented. If you need sub-second responses, EDI is architecturally the wrong choice.
**Fintech.** Almost entirely API-first. The rare exception (ACH NACHA files, SWIFT messages) is closer to EDI in spirit but has its own dedicated ecosystem.
When you need both
This is where 90% of enterprise integration engagements actually land: EDI on the outside, APIs on the inside. Your legacy trading partners send you X12 850s over AS2, an EDI gateway parses them into JSON, an internal REST/GraphQL API exposes the parsed documents to the rest of your organisation, and business logic runs on the API layer where developers actually want to work.
This hybrid pattern lets you keep the trading-partner contracts (which are worth millions of dollars a year) while modernising the internal developer experience (which is worth engineering velocity and retention).
The decision framework
Ask three questions:
**1. Who is your counterparty?** If they already have an EDI stack, meet them where they are. If they don't, don't drag them into EDI.
**2. Are you in a regulated vertical?** Healthcare, government procurement, some financial services — EDI is mandated. The question isn't 'if', it's 'how'.
**3. Is this batch or real-time?** EDI is optimised for batch. Real-time use cases are almost always better served by APIs, even if you have to sit on top of an EDI-based system of record.
The Origami POV
Ninety percent of the 'EDI vs API' arguments we walk into are false dichotomies. Almost every real-world B2B integration is EDI at the boundary and APIs everywhere else. What matters is the quality of the layer between them: how fast a trading partner can be onboarded, how cheaply a transaction moves, how much observability you get for free, and how many senior engineers you have to hire to keep it alive.
If you want to see how we've applied the same 'legacy on the outside, modern APIs on the inside' pattern to document intelligence, see our Document Intelligence product.