EDI vs API: is EDI still used, and what replaces it?
Two questions arrive together. Is EDI still used, or has something replaced it? And is an API the modern version of the same thing? The short answers are yes, and no. A supplier asked to trade with a retailer is, today, usually still handed a compliance guide that names EDI documents. APIs exist beside EDI and do different jobs. The confusion is worth clearing up, because the choice is rarely the supplier's to make, and because it can send a project in the wrong direction before anyone asks the retailer.
What each one is
EDI is an agreed set of business documents in a fixed format. The purchase order, the order response, the advance ship notice and the invoice travel between two systems in a standard layout that both sides have agreed in advance, through a network or a direct connection. The retailer's guide decides which documents, which fields, and the order in which they must arrive.
An API is a way for one system to ask another for something, or tell it something, in real time. Each platform publishes its own: its own fields, its own rules, its own limits. There is no shared layout for a purchase order the way there is in EDI. An API is a doorway. What goes through it is whatever the owner of the door has defined.
Is EDI still used?
Yes. Retailer compliance guides and supplier onboarding packs still specify EDI documents for orders, ship notices and invoices, and the networks that carry them are still how many suppliers connect. EDI is old, and it survives because it solves a coordination problem: thousands of suppliers and a few buyers, and one agreed way to talk.
What is replacing it?
Mostly nothing is replacing it. APIs have grown beside it, in the places where a standard document is not the point:
- Marketplaces and web stores, where each platform defines its own interface for orders, stock and prices.
- Fast-changing data, such as stock levels or order status, where a request and an answer in seconds suits better than a batch of documents.
- Some networks, which now expose their EDI service through an API, so the supplier's system talks to the network one way while the retailer still receives the standard document.
That last case is the useful one to remember. The two are not opposed. An API can be the way a supplier's ERP reaches an EDI network.
Which one does a supplier meet?
The retailer decides. A supplier asked for EDI does EDI. A supplier selling through a marketplace uses that marketplace's interface. Most mid-sized suppliers end up with both, one per major customer, which is the same pattern as the order models they trade under. The useful question is not which technology is better. It is which one each customer requires, and whether the ERP can feed both from the same data.
The trap is treating an API project as a way around a retailer's EDI requirement. A marketplace connection does not satisfy a retailer's compliance guide, and a retailer's EDI documents do not feed a web store. Two customers can mean two requirements, met from one product master, with a clear owner for each.
What has to be right either way
The technology changes the door. It does not change what has to go through it. A purchase order is rejected when a location is not mapped. An advance ship notice is rejected when the pack data does not match the cartons. An invoice is rejected when its price disagrees with the order. None of that depends on whether the document travelled as EDI or through an API. It depends on the product data, the locations and the prices inside the ERP.
That is why a supplier weighing EDI against an API should settle the data first. A clean product master, correct GLNs and pack configurations that match the physical cartons serve both. A perfect connection to an untidy product master serves neither.