APIs Won't Fix EDI. The Compliance Burden Will.

Every few months, someone on LinkedIn declares that retailers need to "just move to APIs" and EDI will finally die. It's a confident take. It's also wrong in a specific and instructive way.

EDI is a data standard. An API is a communication method. Those aren't the same category of thing any more than "English" and "telephone" are the same category of thing. You can ship a beautifully documented REST API and still have every retailer define their own required fields, their own valid values, their own product identifiers, their own ASN structures, their own exception codes. Congratulations: you just rebuilt EDI fragmentation in JSON, and now it has OAuth.

The protocol was never the problem. The real question, the one retailers, platforms, and suppliers have been dancing around for thirty years, is this: who owns the compliance burden?

Why "Move to APIs" Is the Wrong Answer to the Right Problem

The protocol debate is a distraction from the data problem. When someone says "EDI is broken," what they usually mean is: onboarding takes months, every retailer asks for slightly different fields, errors are cryptic, and chargebacks show up for reasons nobody can explain. All of that is true. None of it is caused by the transport layer. A supplier shipping to Walmart, Target, UNFI, and Kroger is managing four different data specifications, four different identifier systems, four different sets of valid values, and four different compliance scorecards, regardless of whether the bytes arrive over AS2, SFTP, a VAN, or HTTPS POST. The protocol is the easy part. Modern EDI platforms support API, AS2, VAN, SFTP, and HTTP out of the box. Nobody loses sleep over that anymore. They lose sleep over the 400-page Walmart vendor guide.

The elegant REST API that still breaks your warehouse

Imagine the best-case scenario. Every large retailer ships a modern REST API tomorrow. Clean endpoints. JSON payloads. OpenAPI specs. Webhooks for status.

Now imagine onboarding to three of them.

Retailer A wants GTINs. Retailer B wants their internal item numbers that bear no relationship to anything else in the universe. Retailer C wants both, in a specific combination, with their DC code appended. Retailer A's ASN accepts carton-level detail. Retailer B requires pallet-then-carton hierarchy. Retailer C sends back "INVALID_HIERARCHY" with no further explanation, and deducts 3% of the invoice.

None of that is an EDI problem. None of it is fixed by changing the pipe.

JSON fragmentation is still fragmentation

The dirty secret of "API-first" retail integration is that APIs, in practice, have produced more fragmentation than EDI, not less. EDI at least had ANSI X12, a shared grammar, even if everyone abused it. REST has no such constraint. Every retailer's API is its own universe, with its own auth flow, its own rate limits, its own field names, its own idea of what "shipped" means. There is no X12 for REST. There is no standards body for purchase order JSON.

So when someone proposes "APIs will fix EDI," the honest translation is: "Let's replace a fragmented standard with a non-standard." That is not progress. That is motion.

What Actually Changes When You Change the Protocol (Hint: Not Much)

The list of things an API fixes, versus the list of things that actually cost suppliers money, barely overlap. APIs are genuinely better at a few things: real-time status, cleaner error responses, easier debugging, webhooks instead of polling. These are real wins. But they sit on top of the same tectonic plates of retailer-specific data requirements that have always been the actual job. Here's the honest scorecard.

Five of the seven things that actually cost suppliers money don't care what protocol you use. Which means the debate we should be having is not "EDI vs. API." It is "who is doing the translation work?"

The Real Question: Who Owns the Compliance Burden?

Every B2B integration has a fixed amount of complexity, and someone has to eat it. Retailer requirements are heterogeneous because retailers have heterogeneous supply chains, warehouse systems, and merchandising logic. That isn't a bug to be fixed; it's a reality to be absorbed. The only question is where the absorption happens. There are really only three options, and they determine everything about how much an integration costs, how long it takes, and how badly it breaks.

Option 1: The supplier owns it

This is the status quo. Every brand figures out Walmart's rules, then Target's, then UNFI's, then Kroger's. They hire an EDI coordinator, or two. They build fragile spreadsheets of "what does this retailer want this field to be." When a retailer updates their guide, someone finds out during a chargeback. This is why brands tell us their first year in retail was "death by a thousand spec PDFs."

Option 2: The retailer owns it

This sounds appealing until you think about it for thirty seconds. Retailers will never standardize on each other's data models; they have real operational reasons for the fields they require. And asking Walmart to accept Target's ASN format is, politely, not a conversation that's going to happen. Retailers own compliance for their own systems; they are not in the business of making life easy for suppliers.

Option 3: The platform owns it

This is the interesting one. A platform layer, sitting between every supplier and every retailer, can absorb the fragmentation on behalf of both sides. The supplier sends one clean representation of a shipment. The platform translates it into whatever Walmart, Target, UNFI, and Kroger each demand, in whatever format each requires, with whatever identifiers each uses. When the retailer updates their spec, the platform updates once, and every supplier on the network benefits.

That is not a protocol question. That is a who-does-the-work question. And it's the only version of this conversation that actually moves the problem forward.

At Crstl, this is the thesis the entire product is built on. We don't care whether data arrives as EDI, JSON, XML, or CSV — we support all of them. What we care about is that suppliers like Freestyle, Immi, and KitchenSupply can sell into Walmart, Target, UNFI, Whole Foods, and Kroger without becoming full-time experts in five different compliance scorecards. The compliance burden lives on the platform. It doesn't live in a Notion doc on the supplier's laptop. That is what "modern EDI" actually means — not the protocol, the ownership model.

What to Ask Instead of "Do You Support APIs?"

When a brand is evaluating an EDI or B2B integration platform, "do you support APIs?" is table stakes. Everyone says yes. It tells you nothing. Better questions to ask:

• When Walmart updates their vendor guide, who updates the mapping — us, or you?
• If a new retailer asks us to onboard, how long until we're sending live documents?
• When a chargeback lands, who decodes the reason code and tells us how to fix it?
• If we sell into five retailers, how many specification documents does our team need to read?
• When the answer to any of the above is "you," what does your team actually do?

Those questions surface the compliance-burden question directly. They are also the questions that predict, better than anything else, whether a supplier will spend their next three years fighting their EDI stack or quietly shipping product.

The protocol was never the point. The point is who carries the bag.

Frequently Asked Questions

Is EDI going to be replaced by APIs?

Not in any meaningful sense. Major retailers continue to require EDI for the majority of B2B document exchange, and modern platforms support EDI, API, AS2, SFTP, and VAN interchangeably. "Replacing" EDI with APIs misunderstands the problem. The data standard and the communication method are different layers.

What's the actual difference between EDI and an API?

EDI is a set of data standards (like ANSI X12 or EDIFACT) defining how business documents are structured. An API is a communication method for exchanging data between systems. You can send EDI-formatted data over an API, and you can send API-style JSON using EDI-like rigor. They solve different problems.

Why do retailers still use EDI in 2026?

Because it works reliably at massive scale, because the existing supplier base runs on it, and because replacing it would require every retailer and supplier to rebuild their integration stack simultaneously. The economics haven't moved. What has moved is the platform layer on top of EDI, which is where modernization is actually happening.

Does using an API-first EDI provider fix retailer compliance issues?

No, not on its own. API-first connectivity makes debugging and real-time status easier, but retailer-specific compliance rules live in the data requirements, not the transport layer. What matters is whether the platform absorbs the compliance work on your behalf, regardless of protocol.

What's the biggest hidden cost of EDI today?

The internal labor required to interpret each retailer's vendor guide, maintain mappings, and respond to chargebacks. Most brands underestimate this by an order of magnitude. Platform cost is visible. Compliance labor is invisible — until it isn't.

How does Crstl handle the compliance burden differently?

Crstl operates as the compliance layer between suppliers and retailers. Brands send a single clean representation of their orders and shipments; Crstl translates into each retailer's required format, identifiers, and hierarchy, and maintains those mappings as retailer specs change. Suppliers stop owning compliance spreadsheets.

The Takeaway

If your B2B integration provider's pitch is "we have an API," they're answering a question nobody should be asking. Ask them who owns the compliance burden when you sign your next retailer. The answer is the only thing that matters.

Want to see what it looks like when the platform owns compliance instead of your team? Book a demo with Crstl — or read how Freestyle cut EDI costs 20% while scaling to 1,300+ retail locations.

Book a Demo → | View Case Studies →