What is EDI, and why is it still used in the API era?
EDI is how two companies exchange trade documents without human hands touching them. Orders, despatch notes, invoices — all in a standard structure, straight from one system to another.
"Why not JSON?"
Every developer meeting EDI asks the same thing: with REST APIs available, why use a text format from the 1980s?
The answer is not technical. A retailer works with thousands of suppliers. Rather than negotiating a separate API with each one, it imposes a single standard: "send us an EDIFACT ORDERS". The standard removes the cost of one party adapting to the other.
And that standard has barely changed in decades. An integration written in 2005 still runs today. That sentence is rarely spoken in the API world.
Who uses it?
- Retail chains — nearly all order and invoice flow
- Automotive — production line supply, just-in-time calls
- Logistics — transport instructions and status reports
- Healthcare and public sector — especially in Europe
Is it really outdated?
The syntax is old; the logic is not. The problem EDI solves — two independent systems agreeing on a shared vocabulary — has not changed. Modern alternatives such as APIs and networks like Peppol solve the same problem with different syntax.
In practice both coexist: many companies use JSON internally and translate to EDIFACT at the boundary.
Where to start
If an EDI file has landed on your desk, the first thing you need is to be able to read it. Opening the file and seeing what the segments mean is the natural first step, long before integration work begins.