API or EDI? Choosing the right pipe for each partner

Two customers onboard you in the same month. One sends a forty-page EDI implementation guideline with a directory version on the front. The other asks, in one line of email, whether you have an API.

It is tempting to treat that as a single question with a single answer: pick a pipe, make everyone use it. That instinct produces either an EDI project you cannot afford or an API nobody you work with will ever call. They are not competing answers to one question. They answer different questions, and which one fits tracks the size and the habits of the counterparty far more than it tracks anything technical.

The difference is semantics, not just plumbing

Both move a transport order from their system into yours without anyone retyping it. What differs is the unit of work, and who is waiting.

EDI’s unit is the interchange: a file, wrapped in an envelope, holding one or more messages, sent on a schedule or when a batch fills. Nobody is online when it arrives. The format in European road freight is usually UN/EDIFACT, published through UNECE as versioned directories, and the message set is settled. IFTMIN, the Instruction message, carries the order. IFTSTA, the International multimodal status report message, carries status back. INVOIC, the Invoice message, claims payment. Because nobody is waiting, problems are reported afterwards by their own messages: CONTRL, the syntax and service report message, acknowledges or rejects the received interchange itself, and APERAK, the application error and acknowledgement message, reports that their application received the message and rejected it during processing. The EDI article walks through that set properly.

An API’s unit is the request. Someone’s software calls yours and waits for the answer. Validation happens at submit time — a missing postcode comes back as a refusal to the caller who can still fix it, rather than as an acknowledgement message an hour later, addressed to whoever reads that mailbox. The reverse direction is a webhook: your system calls theirs when something happens, instead of them fetching a status file on a timer.

That distinction decides most of the rest.

What EDI is genuinely good at

It is an agreement as much as a format. The guideline, the code mapping and the acknowledgement rules are the expensive part, and they are also the durable part. Once that agreement exists, volume through it is close to free.

The counterparty already has it. A large shipper has people whose job is adding an EDI partner. Those same people cannot usually get budget to write a bespoke client for one carrier’s API. Your API is your project; their EDI is their process, and processes win.

Batch semantics suit contracted freight. Repeating, predictable volume that tolerates latency measured in minutes is exactly what an interchange is for.

It outlives the person who set it up. A directory version and a written guideline are documents. The developer who wired them will move on; the documents stay, and the next person can read them.

What an API is genuinely good at

It is cheap to stand up. No guideline to negotiate, no directory version to agree on. Keys, endpoints, documentation — days rather than a quarter.

It is interactive. The error lands on the person who caused it, while the booking is still on their screen. That single property removes a whole category of Friday afternoon: the rejected file nobody looked at until Monday.

It serves the long tail. A customer sending a handful of loads a week can wire a script, a form or their own back office to it without a project.

It serves your own edges. The customer portal, the driver app, the spreadsheet macro someone in the office wrote — all of them are API clients, which means the API earns its keep before an external partner ever calls it.

The honest trade-off: an API’s flexibility is also its instability. Nothing imposes version discipline the way a published directory does, so you own backwards compatibility for as long as anyone is calling. And offering an API moves the integration work onto the customer, who may have nobody to do it. We have an API is not an answer to a partner who was hoping you would do the integrating.

The dividing line is who does the work

Strip the technology out and the question becomes: which side conforms to something the other side already has?

• A large shipper or a retail chain. EDI, on their guideline. Their scale pays for it, they will not deviate for one carrier, and declining is a commercial decision rather than a technical one.
• A mid-sized customer with an IT person, a broker, or a freight platform. An API, usually. They are capable of calling one and have no EDI department to satisfy.
• A small customer. Very often neither. A customer portal or a file drop answers what they actually want, which is generally not to retype anything and to stop phoning you for status. It is worth asking directly — EDI required on a tender sometimes turns out to mean precisely that.

None of these are judgements about which technology is better. They are judgements about where the integration effort can realistically sit.

Why both is normal, and what makes it affordable

Running two pipes does not cost two pipes. It costs two versions of the truth, and that is the expensive part.

A booking that arrives as an IFTMIN and a booking that arrives as an API call have to become the same record, with the same statuses, the same documents and the same route to an invoice. If each channel gets its own table, its own status vocabulary and its own exceptions, you have bought two systems, and the seam will surface somewhere costly — usually on an invoice, in front of a customer.

So the useful question to ask of the system underneath is not does it support EDI or does it have an API. It is: do both land in the same booking? And its counterpart on the way out — when a driver marks a delivery complete, does that one event become an IFTSTA for the customer who wanted EDI and a webhook for the customer who wanted an API, without anyone entering it twice?

The questions that apply to both

Whichever pipe a partner gets, the same five things decide whether it keeps working:

1. Who notices when it stops? The skipped question in every integration conversation. A silent pipe is worse than no pipe, because everyone carries on assuming the orders are flowing.
2. What is the acknowledgement, and does a human ever see it? EDI has CONTRL and APERAK; an API has status codes and error bodies. Both are useless if they only reach a log nobody opens.
3. What are the duplicate rules? A resent file and a retried request are the same hazard: one order becoming two loads. Both sides need an agreed identity for an order and a rule for what happens when it arrives twice.
4. What is the fallback? When the link is down, does the work stop, or is there an email path and a way to reconcile afterwards?
5. Who pays when the other side revises? Guidelines get updated and APIs grow new required fields. Someone is doing that work next year.

Answer those per partner and the choice of pipe stops being an identity question about your company and becomes what it is: a per-relationship decision, revisited when the relationship changes.

Where navichain fits

The point of the system underneath is that the channel stops being an architectural decision and becomes a per-partner one. navichain ships a REST API built for ERP and TMS integration — API keys with scopes over bookings, organizations, tracking and document endpoints, with webhooks, rate limits and an audit trail on every call — alongside the freight-partner integrations most Nordic operators already meet in the wild: Opter, LogTrade, EDIFACT and Fraktjakt. There is a customer portal for the customers who need neither. All of it feeds one booking record, and because every feature is included on every plan, adding a partner on a different pipe does not move you up a price tier. The platform page sets out what is inside, and pricing is a single page with no per-integration line.