What is EDI, and why is it still used in the API era?
EDI is the exchange of commercial documents between two companies without human hands in the middle. Orders, despatch notes, invoices — all in a standard structure, straight from one system to another.
"We have JSON. What is this?"
Every developer who meets EDI for the first time asks the same question: why use a text format from the 1980s when you could write a REST API today?
The answer is commercial, not technical. A retail chain 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 shifts the cost of adapting from the chain to the supplier — and for the supplier it is still cheaper than writing a bespoke integration per customer.
The real issue: the N×M problem
Say there are 500 suppliers and 20 chains. If everyone spoke their own API, you would in theory need 10,000 separate integrations. A shared standard reduces that to 520: each party learns the standard once.
That is the problem EDI actually solves, and it has nothing to do with technology. Change the format and the problem remains; modern networks such as Peppol work on the same logic, only with a different syntax.
Who uses it?
- Retail chains — almost the entire order and invoice flow. If you want to
supply a supermarket, EDI is often a contractual requirement.
- Automotive — feeding the production line and just-in-time delivery calls.
Here a delay means the line stops.
- Logistics — shipping instructions, transport status reports, customs
documents.
- Healthcare and the public sector — particularly tendering and invoicing in
Europe.
For most people the first encounter looks the same: a specification from a customer with a sample file attached.
What does an EDI message look like?
These four lines are the beginning of a purchase order:
UNB+UNOC:3+8712345678901:14+8798765432109:14+260117:1030+REF00042'
UNH+ME000001+ORDERS:D:96A:UN:EAN008'
BGM+220+PO-2026-0042+9'
NAD+BY+8798765432109::9++MEGA RETAIL AS+Barbaros Bulvari 12+ISTANBUL+34353+TR'
It looks impenetrable, but the logic is simple. Each line is a segment, and the three letters at the start say what that segment is about:
| Segment | Meaning |
|---|---|
UNB | Interchange header: from whom, to whom, when |
UNH | Message header: this is an ORDERS, version D.96A |
BGM | Document number: PO-2026-0042 |
NAD | Party details: BY means buyer |
Inside a segment, + separates data elements, and : splits an element into components where needed. That is the whole structure; the rest is knowing what each code means.
So is it really outdated?
The format is old; the logic is not. The problem EDI solves — two independent systems agreeing on a shared vocabulary — is the same today.
The standard is also remarkably stable. An integration written in 2005 may still run unchanged. That sentence is rarely spoken in the API world, where version bumps, removed endpoints and changing authentication schemes are routine work. In EDI, "if it works, leave it alone" is genuinely possible.
What the format costs you is readability. It is a compact syntax that was never designed for humans, which is exactly why you need the right tool when debugging.
How do EDI and APIs coexist?
In practice they sit side by side. The common arrangement is:
- Internal systems speak JSON among themselves
- A translation layer sits at the boundary to the outside world
- That layer converts outgoing data to EDIFACT and incoming EDIFACT to JSON
EDI usually lives at the edge of the application rather than inside it. This distinction matters: modelling your business logic on EDI segments hurts in the long run. Keep your own data model and translate at the boundary.
Where to start
If an EDI file has landed on your desk, the order of work is:
1. Make the file readable. Which message type, which parties, which line items? Do this before you touch any integration code. 2. Ask your partner for their specification. EDIFACT is broad; every partner defines its own subset and mandatory fields in a separate document. The standard alone is not enough. 3. Compare the sample file against the specification. If a field the spec calls mandatory is empty in the sample, that usually means the spec is out of date rather than that you are wrong. Asking saves time. 4. Then write code. Before writing a parser, make sure you have actually seen what the file contains.
A browser-based viewer is enough for the first step: you can see what the segments mean without uploading the file anywhere.