EDI or API: Which One a Small Distributor Actually Needs

A buyer at one of your largest accounts sends a short email. From the first quarter, all suppliers must trade documents by EDI. No discussion, and no alternative address for purchase orders.

The same week your developer says the whole thing is dated, and that a modern API would do it in a fortnight.

Both are partly right. The question is not which technology is better. It is which partner sets the rules for which flow, and who maintains it in two years.

The short answer: Most small distributors need both, split by partner. Use Electronic Data Interchange (EDI) for the trading partners who mandate it, because their format is a fixed input you cannot negotiate. Use an application programming interface (API) for the systems you control. For two or three partners, a shared order form and a person often beats both.

EDI is a standardized document format that trading partners exchange as structured messages, using agreed types such as a purchase order or an invoice. This article does not recommend a product. Most pages that rank on this question are published by vendors who sell one side of it.

What is EDI, and what is an API?

EDI is old, specified and stable. In North America the standards come from the Accredited Standards Committee X12, which defines and maintains the transaction sets used across the supply chain: 850 for a purchase order (PO), 855 for a PO acknowledgment, 856 for a ship notice or advance ship notice (ASN), 810 for an invoice, 846 for inventory and 820 for remittance advice. Elsewhere the equivalent is UN/EDIFACT, whose directories are published by UNECE with messages named ORDERS, ORDRSP, DESADV and INVOIC. Retail grocery largely runs on GS1 EANCOM, a subset of UN/EDIFACT that carries GS1 product and location identifiers.

Transport is specified too. AS2, defined in RFC 4130, packages business data as MIME over HTTP with signing and encryption, and returns a Message Disposition Notification (MDN) as an authenticated acknowledgment of receipt.

An API is the other model. Rather than exchanging documents, two systems call each other continuously: yours asks for orders, posts stock levels, pushes an invoice. The format is defined by whoever publishes the API, and it changes when they change it.

The difference that decides your case is not speed. It is who owns the format.

Which one does each trading partner actually let you choose?

Start here, because it removes most of the argument.

A large retail or grocery partner that mandates EDI is a fixed input. You will not talk them out of it. The documents they require, the identifiers they use and the timing windows are in their supplier pack. Treat that pack as a specification, not a preference.

Everyone else is a choice. A dealer ordering from your website, a partner with no requirement, your own warehouse or third-party logistics provider (3PL): those flows are yours, and an API or a portal is usually simpler.

So the first thing to produce is not an architecture diagram. It is a list, one row per trading partner: what they require, which documents, how many orders a month, and who owns it after launch.

How do EDI and an API compare on the dimensions that decide it?

	EDI	API
Who sets the format	The trading partner, inside a published standard	Whoever publishes the API
Latency	Batched, often in scheduled windows	Continuous, request by request
Setup cost shape	Mapping and testing per partner	Build once per integration
Ongoing cost shape	Subscription plus per-document or network fees	Engineering time, hosting, version upkeep
Error visibility	Acknowledgment messages built into the standard	HTTP status codes and alerting you build
Skills needed	Document mapping and partner compliance	Developers who own the code
Typically breaks when	A partner changes their spec or an identifier is wrong	The publisher versions, throttles or deprecates
Good fit	Partners who mandate it, high document volume	Your own systems, partners who publish an API

Two documented examples make the row about error visibility concrete.

On the EDI side, X12 publishes the supply chain transaction flow as an ordered exchange: the buyer sends an 850, the seller replies with an 855, then sends an 856 before delivery and an 810 to bill, and the buyer sends an 820. Each transaction is answered by a 997 functional acknowledgment confirming it was received and usable. Nothing moves silently. AS2 adds the signed MDN on top.

On the API side, you build that yourself. Shopify documents a calculated query cost model with a leaky bucket, where an app spends points per second according to plan and receives a throttle error when the bucket is full, so your code has to back off and retry. It also documents that it retries a failed webhook up to eight times in a four-hour period, then removes the subscription. Both are reasonable, and both are yours to handle. Neither tells your operations team anything unless you build failure alerts.

What is the third option nobody sells?

For two or three partners, a shared order form or a small portal plus a person beats both.

A buyer fills in a form that only offers stock keeping units (SKUs) and prices they are entitled to. The submission lands in your enterprise resource planning (ERP) system or store as a real order. Somebody checks the exceptions. No mapping fees, no certification, no engineering on call.

This is not a lesser answer. It removes the retyping, which is where the cost sits, for partners who never asked for a standard. If those partners reorder the same items regularly, the question becomes whether to build or buy the reorder portal, not whether to buy EDI.

The honest limit: it does not satisfy a partner who mandates EDI, and it stops scaling when one person cannot keep up with the exceptions.

What does each one really cost?

The costs sit in different places, which is what makes comparison hard.

EDI cost is mostly recurring and linked to volume. You typically pay a service provider a subscription, plus per-document or network charges, plus a one-off mapping and testing fee for each new partner. It grows as document count grows.

API cost is mostly up front and linked to people. You pay for a build, then for the time to keep it working through version changes, credential rotations and the partner's own releases.

Here is the shape, with illustrative numbers. Use your own rates.

Two partners mandate EDI. You trade four documents per order (850, 855, 856, 810) on 75 orders a month each, so 600 documents a month.

• Service subscription: €250 a month
• Documents: 600 × €0.10 = €60 a month
• Year one: (€250 + €60) × 12 = €3,720, plus a one-off mapping fee per partner

One further partner publishes an API and does not require EDI.

• Build: 50 hours × €80 = €4,000 once
• Upkeep: 2 hours a month × €80 = €160 a month, or €1,920 a year
• Year one: €5,920. Year two: €1,920

The API costs more in year one and less afterward, and it does not grow with document count. The EDI line is smaller now and rises with every new partner and every extra document. Neither is cheap, and both numbers are illustrative. Run yours the same way you would price any other automation decision.

Who owns it after launch?

This question kills more integrations than any technical one.

EDI ownership usually looks like a relationship with a service provider plus someone internal who reads partner compliance notices and handles rejected documents. It is an operations job.

API ownership is an engineering job. Someone reads deprecation notices, upgrades versions, rotates credentials and responds when a retry window closes. If that person is a contractor who finished six months ago, you do not have ownership. You have a countdown.

Write the owner's name next to each partner row before you sign anything. That line belongs in your B2B integration checklist alongside the technical ones.

When is neither worth doing?

• One partner, low volume. Twenty orders a month by email does not justify either.
• The partner has not actually mandated anything. Ask before you build. "It would be nice" is not a requirement.
• Your product data is not ready. EDI fails on identifiers. If your SKUs, barcodes and locations are inconsistent, fix that first or every document gets rejected.
• Nobody will own it. See above.
• The flow is a negotiation. Quotes, custom pricing and credit decisions stay with people.

What should you measure?

Before you commit, write down per partner:

• Orders per month, and documents per order
• Minutes of manual handling per order today
• Rejected or non-compliant documents per month, and how you found out
• Time from PO received to acknowledgment sent
• Chargebacks or penalties from partner compliance programs

After launch, the numbers that matter are rejections, manual touches per order and time to acknowledgment. If manual touches did not fall, the integration moved the work rather than removing it. Warehouse-side flows deserve the same treatment, since 3PL integration errors show up as missing ship notices long before anyone calls them an EDI problem.

How do you decide this week?

1. List every trading partner and what each one actually requires, in writing.
2. Mark the mandates. Those rows are EDI, and the decision is made for you.
3. For the rest, count orders per month and minutes of manual handling per order.
4. For any partner under a few orders a week, price the form-plus-a-person option first.
5. Name an owner for every remaining row before you ask a single vendor for a quote.

Partner requirements first, volume second, ownership third. Everything else follows, and it sits inside the wider B2B automation audit rather than replacing it.

FAQ

Is EDI obsolete?

No. EDI standards are actively maintained: X12 publishes and updates its transaction sets, UNECE publishes UN/EDIFACT directories, and GS1 maintains EANCOM for retail supply chains. Large retail, grocery and automotive partners still mandate it, so for those relationships it is a current requirement rather than legacy technology.

Do I have to use EDI if my customer asks for it?

If they mandate it, yes, or you stop trading with them. Ask for the supplier pack and read it before you agree to anything. It names the documents, identifiers, timing windows and testing steps, and those are the real scope of the work.

Can an API replace EDI with a large retail partner?

Usually not. The partner sets the format, and their systems are built around standardized documents exchanged with hundreds of suppliers. Some partners now offer an API alongside EDI, so it is worth asking, but treat the answer in their supplier pack as the constraint rather than something to negotiate.

Which EDI documents does a small distributor usually need?

Most start with the purchase order, the purchase order acknowledgment, the advance ship notice and the invoice, with inventory and remittance advice added later. The exact list comes from each partner. In X12 terms that is the 850, 855, 856 and 810, and in UN/EDIFACT terms ORDERS, ORDRSP, DESADV and INVOIC.

Is EDI or an API cheaper?

They are cheap in different ways. EDI cost is mostly recurring, through subscriptions and per-document or network fees that grow with volume. API cost is mostly up front, in engineering time, plus ongoing upkeep as versions change. Compare them over three years per partner, not as a single sticker price.

Do I need both EDI and an API?

Most distributors with a mix of partners end up with both, plus a portal or order form for the smallest accounts. Split the decision by partner rather than picking one technology for the whole business, and give each flow an owner.

Sources

• X12: Transaction Sets for the maintained X12 transaction sets.
• X12: Supply Chain Transaction Flow for the documented 850, 855, 856, 810, 820 and 997 sequence.
• UNECE: UN/EDIFACT Directories for the UN/EDIFACT message directories.
• GS1: EANCOM for EANCOM as a UN/EDIFACT subset with GS1 identifiers.
• RFC 4130: AS2 for AS2 transport, signing, encryption and MDN receipts.
• Shopify developer docs: Rate limits for calculated query cost, the leaky bucket and throttling.
• Shopify developer docs: Troubleshoot webhooks for the webhook retry window.