Skip to content 
API vs EDI in freight compares two ways systems exchange shipment data: EDI sends standardized documents in batches, while an API lets software request and receive data on demand.
Both move the same business events: a load tender, a status update, an invoice. The difference is how and when. EDI has carried freight transactions between shippers, carriers and forwarders for decades, and it is still the backbone of many retail and enterprise programs. APIs are how most newer rating, booking and tracking connections are built, including the ExFreight freight API. For a shipper or 3PL deciding how to connect the next partner, the useful question is not which technology is better, but which one fits each flow.
Key takeaways
- EDI exchanges fixed-format documents (ANSI X12 in North America) in batches over AS2, SFTP or a VAN. APIs exchange data on request, one call at a time.
- Interactive steps such as rate shopping and tracking lookups favor APIs. High-volume, contract-bound document flows such as tenders and invoices are still often EDI.
- Most mature freight programs run both, so map each business event to the channel that serves it best.
API vs EDI in freight: the core difference
EDI is a document exchange. A sender’s system builds a standardized file, such as an X12 204 load tender, and transmits it to a trading partner. The partner’s system translates it, acts on it and may send a document back, such as a 990 response. Transmissions often run on a schedule, and both sides must agree on an implementation guide before the first file moves.
An API is a conversation. Your system calls a service with a request (“rate this shipment”, “where is this booking”) and gets a structured answer in the same session. There is no separate translation layer and no waiting for the next batch window. The trade-off is that API formats are set by each provider, so two carriers can describe the same event in different ways.
| EDI | API | |
|---|---|---|
| Timing | Batch, on a schedule agreed with each partner | On demand, per request |
| Connection | AS2, SFTP or a value-added network (VAN) | Secure web calls between systems |
| Format | Rigid standard transaction sets (ANSI X12) | Provider-defined schemas, with emerging industry standards |
| Best for | High-volume documents: tenders, invoices, ship notices | Interactive steps: rates, bookings, status lookups |
| Onboarding | Partner mapping and testing per trading partner | Developer build against the provider’s test environment |
| Error handling | Acknowledgments (997 or 999) after the batch is processed | Validation errors returned on the call |
That last row matters more than it looks. When an API rejects a request with a bad postal code or a missing dimension, the user who entered it is still on the screen and can fix it. An EDI rejection can arrive hours later, after the shipment has moved on to the next step.
EDI transaction sets in freight and their API equivalents
The X12 standard, maintained by X12, defines the transaction sets that freight teams know by number. Here is how the common ones line up with the API calls that carry the same business event.
| X12 set | Official name | Business event | API equivalent |
|---|---|---|---|
| 204 | Motor Carrier Load Tender | Shipper offers a load to a truck carrier | Booking request |
| 990 | Response to a Load Tender | Carrier accepts or declines | Booking confirmation in the response |
| 211 | Motor Carrier Bill of Lading | Shipment terms and contents | Booking details or bill of lading call |
| 214 | Transportation Carrier Shipment Status Message | Pickup, in transit, delivered | Tracking request |
| 210 | Motor Carrier Freight Details and Invoice | Carrier bills the shipment | Invoice retrieval |
| 300 / 301 | Reservation (Booking Request) (Ocean) / Confirmation (Ocean) | Ocean booking and its confirmation | Ocean booking request and confirmation |
| 315 | Status Details (Ocean) | Container and vessel milestones | Ocean tracking request |
| 997 / 999 | Functional / Implementation Acknowledgment | Receipt and syntax check | Response status and validation errors |
Note what is missing from the left column: there is no widely used X12 set for instant rate shopping across carriers. Rating has always been an interactive question, which is why rate requests moved to APIs first. Booking and tracking followed. For the detail of each flow on the API side, see the freight booking API and freight tracking API guides.
Worked example: one LTL shipment, two channels
A distributor ships 3 pallets from Atlanta to Dallas. Over EDI, its TMS sends a 204 to the chosen carrier; the carrier returns a 990; 214 status messages arrive as the carrier’s batch cycle runs; a 210 invoice follows delivery. Over APIs, the TMS rates the shipment across options, books the selected option and receives the confirmation in the same session, then requests tracking status when a user or a rule needs it. The events are identical. What changes is who waits, and for how long.
When EDI still wins
EDI is not legacy in the sense of obsolete. It remains the right channel in several situations:
- Mandated programs. Many large retailers and manufacturers require X12 from their carriers and suppliers. If the partner mandates it, the decision is made.
- High-volume, predictable flows. Thousands of contract tenders or invoices a day move efficiently as batches, and the partner’s audit tools are built around X12 documents.
- Established mappings. A working EDI connection with years of mapping fixes behind it is an asset. Replacing it only for novelty adds risk without new capability.
- Document-centric audit. Freight audit and payment processes often expect 210 invoices in standard format.
APIs win where the user needs an answer while still deciding: comparing rates, confirming a booking, checking a shipment’s location for a customer on the phone. They also win where no EDI mapping exists, such as onboarding a new forwarder for a few lanes, or where the data changes faster than a batch cycle can report it, such as a missed pickup that sales needs to know about before the customer calls.
Hybrid setups
Most programs settle on a hybrid. A practical way to design one:
- List business events. Rate, book, confirm, status, proof of delivery, invoice. Write down the system of record for each.
- Classify each event. Interactive (someone is waiting) or batch (the result is consumed later). Interactive events go to APIs.
- Respect partner mandates. Where a partner requires EDI for a flow, keep it, and translate into your internal model at the edge.
- Use one internal shipment model. Normalize X12 segments and API fields into the same record so reporting does not care which channel delivered the data.
- Reconcile quotes to invoices. Whether invoices arrive as 210s or through an API, compare them with the rated request on weight, class, accessorials and scope.
Rates returned through any channel are informational and subject to change. If the tendered freight or the services used differ from the request, the shipment can be re-invoiced to match the actual details. Reconciliation catches the pattern; accurate request data prevents it.
Questions to ask before connecting a new partner
- Which events does the partner support, and on which channel? Rating, booking, status and invoicing may each be offered differently.
- Is there a test environment? A sandbox or test account shortens onboarding for both EDI and API builds.
- How are status events coded? Map the partner’s milestones to your own list before go-live, not after the first exception.
- Who owns errors? Agree who monitors rejected requests and failed acknowledgments, and how fast they are fixed.
Standards bodies are working to narrow the API side’s biggest weakness, fragmentation. NMFTA’s Digital Standards Development Council publishes open API standards for LTL and truckload, which gives motor freight a shared vocabulary closer to what X12 provides for documents. If you connect through a TMS rather than building calls yourself, the TMS carrier integration guide explains how connectors carry both kinds of traffic.
ExFreight’s connectivity is offered as APIs for quoting, booking and tracking, and existing TMS integrations include Project 44, Accufrate, Banyan, SAAS, 7L, Primus, Pacejet, CSA Software and Teknowlogi.
What ExFreight’s API covers today
The APIs are available upon request, with a test environment and assistance. Connectivity gives access to ExFreight’s online rating, booking and tracking system. See how the ExFreight freight API works
Freight API series
Frequently asked questions
What is the difference between API and EDI?
EDI exchanges standardized business documents, such as X12 load tenders and invoices, between trading partners, often in scheduled batches over AS2, SFTP or a VAN. An API lets one system request data or an action from another on demand and get the answer in the same session. EDI suits volume documents; APIs suit interactive steps.
Is API replacing EDI?
Not wholesale. APIs are taking over interactive freight steps such as rate shopping, booking and status lookups, while EDI remains embedded in mandated retail programs, contract tendering and invoicing. Most shippers and carriers run both and add APIs where speed matters, rather than ripping out EDI connections that already work.
What has replaced EDI?
Nothing has fully replaced EDI. In freight, APIs now handle much of the interactive work EDI never served well, such as instant rating and on-demand tracking, and industry groups such as NMFTA publish API standards for motor freight. X12 documents still carry large volumes of tenders, status messages and invoices.
Is EDI still a thing?
Yes. EDI is still widely used in freight and retail supply chains, especially for load tenders (X12 204), shipment status (214) and freight invoices (210). Many large shippers require it from carriers and suppliers. What has changed is that new interactive connections, such as rate and booking integrations, are usually built as APIs.
Will EDI be replaced by AI?
AI does not replace the need for a structured data exchange; it consumes one. AI tools can help map EDI segments, flag exceptions and read unstructured documents, but trading partners still need an agreed format and channel, whether X12 documents or APIs, to move tenders, status and invoices reliably between systems.
