The question is never really “API or EDI”. It is “which of my carriers can send me a status message at all, and in what form”. A European shipper with forty carriers usually ends up running both channels at once, because the top five can hold an EDI mapping open and the other thirty-five cannot. That is the situation a road freight visibility API is built for, and it is the reason the choice matters less than most integration projects assume.
What follows is the comparison as it plays out on a European lane, not as a protocol debate.
What each one actually is
EDI is a set of agreed message formats plus an agreed way of moving files. In European road freight that almost always means EDIFACT: IFTMIN to tender a transport instruction, IFTSTA to report status, IFTMAN for the arrival notice, DESADV for the despatch advice the receiving warehouse books against. The files move over AS2, SFTP, OFTP2 in automotive, or through a value-added network that charges by volume. A partner connection is a project with a specification, a mapping and a test cycle.
An API is an endpoint your system calls, or that calls you. JSON over HTTPS, a token for authentication, a documented set of fields, and no per-partner specification because the specification is the same for everyone. Where EDI negotiates a format per relationship, an API publishes one format and asks partners to meet it.
Both carry the same facts. The difference is in the shape of the work: EDI moves the cost into the connection, an API moves it into the integration you build once.
Batch against event
This is the distinction that decides everything downstream, and it gets lost when the comparison is framed as old against new.
EDI is file-shaped. Messages accumulate and are transmitted on a schedule, commonly every fifteen minutes to an hour, sometimes overnight for non-urgent message types. Even when the transmission window is short, the pattern is a batch: a file arrives, it is parsed, and everything inside it is processed at once.
An API is event-shaped. A position or a status change is pushed the moment it is known, or pulled when you ask. The gap between the truck crossing the geofence and your TMS knowing about it is seconds rather than the remainder of the batch window.
For invoicing and despatch advice, batch is fine and always has been. For anything a dispatcher acts on within the hour, batch latency is the whole problem. This is also where the difference between visibility and tracking becomes concrete: a nightly IFTSTA file gives you a record, not visibility.
What a small carrier can actually support
Integration plans fail here more often than on any technical point.
A carrier running two hundred trucks with an IT team can hold an EDI mapping open, absorb a format change and test a new message type. A carrier running twelve trucks cannot, and in most European networks the twelve-truck operator is the majority of your partners by count even when the large carriers are the majority by volume.
What the small carrier does have is a telematics box, because the tachograph and the fleet management contract already put one in the cab. That box has an API. Connecting to the telematics provider once gives you position data from every subscriber of that provider, which is why platform-mediated visibility scales where bilateral EDI does not: one integration, many carriers, no project per relationship.
The practical consequence is that a shipper choosing EDI exclusively is choosing to have visibility over the top fifteen per cent of its carrier base and nothing over the rest.
Cost and time, honestly
EDI costs sit in three places. There is the setup for each partner connection, typically four to twelve weeks from specification to production for a message pair with a partner who has done it before, and longer with one who has not. There is the mapping itself, which is bespoke work every time a partner interprets a segment differently, and they do. Then there is the running cost: VAN charges by data volume, or the internal cost of an AS2 stack somebody has to keep certificates valid on.
API costs sit in one place and then stop. The integration is built once against a documented endpoint. Adding the forty-first carrier costs an account and a test call rather than a project. The recurring cost is monitoring, which you needed anyway.
The honest asymmetry is at the start: if the partner already runs EDI with you and the message already exists, using it is nearly free, and rebuilding that flow as an API buys nothing. Nobody should migrate a working INVOIC flow for architectural tidiness.
Where EDI still wins
Four situations, and they are not edge cases.
- Retail compliance. When a grocery or DIY retailer mandates DESADV and a specific label, that is the channel. There is no API alternative on offer and the penalty schedule is real.
- Automotive. OFTP2 and the Odette message set are embedded in the supply chain and in the audit expectations around it. Call-off and delivery instruction flows are not moving.
- Volume that is genuinely batch. Monthly self-billing, freight invoice reconciliation, rate tables. A file is the correct shape for these and an API adds nothing but calls.
- Legal and archival weight. Where the message has to be archived in an agreed structured form for years, a mature EDI archive is a solved problem. The same argument applies to consignment notes, which is a separate discussion covered in the comparison of eCMR and paper CMR.
Running both without paying twice
The workable architecture is not a migration, it is a translation layer. Both channels land in the same place, get normalised into the same internal event, and the systems downstream never learn which channel a given event arrived on.
Three rules make that hold up:
- One internal event model. An arrival is an arrival whether it came from an IFTSTA segment or a webhook. Define the field set once, including which timestamp is authoritative, and map into it at the edge. Skip this and you get two parallel truths, which is worse than either channel alone.
- Idempotency at the boundary. EDI files get resent and webhooks get retried. Every inbound event needs a key that makes reprocessing harmless, otherwise a resent file rewrites history with duplicate arrivals and every dwell number you publish is wrong.
- One reconciliation report. Count events per carrier per week by channel. This is the report that reveals a carrier who stopped sending three weeks ago, which is the most common silent failure in both channels and the reason the number on a road freight KPI dashboard drifts without anybody touching it.
The migration path, where there is one, runs partner by partner in the direction of least resistance. Move a partner when their EDI mapping is already due to change, never as a project of its own. Keep the EDI flow live in parallel for a month and compare event counts before switching the downstream consumers over. Retire the mapping only once the counts have matched for four weeks.
The decision itself is smaller than it looks. Pick the channel each partner can actually sustain, normalise both into one event model, and spend the saved effort on the part that genuinely determines whether any of it works: how many of your carriers are connected at all, and whether the events they send are trustworthy. That question, not the protocol, is what separates a working visibility programme from a project that produced a specification. Where to house the resulting flows is a related but separate choice, set out in the guide to 3PL and 4PL models.
