If you're building a transportation management system (TMS), a freight brokerage platform, or any software that needs to exchange data with carriers, you will encounter the EDI vs API decision early. Both approaches solve the same core problem - getting structured data from your system into the carrier's system and back - but they do it in fundamentally different ways with very different cost structures, implementation timelines, and operational requirements.
This guide is written for developers and technical product managers who need to understand both approaches deeply enough to make a defensible architecture decision. We'll cover how EDI actually works (including the specific X12 transaction sets used in freight), what modern REST API freight integration looks like, a realistic cost comparison, and the scenarios where each approach is the right choice.
EDI stands for Electronic Data Interchange. It is a set of standards for computer-to-computer exchange of business documents in a standardized electronic format. The dominant standard in US freight is ANSI X12, developed by the Accredited Standards Committee X12 (ASC X12). EDI has been used in freight since the 1980s and is deeply embedded in the technology stacks of major carriers, large shippers, and legacy TMS platforms.
EDI messages are called "transaction sets." Each transaction set has a number and covers a specific business document type. The transaction sets most relevant to freight operations are:
The 204 is used to tender a load to a carrier. It includes origin and destination, commodity and weight, pickup and delivery dates, and the rate. When a shipper or broker sends a 204, they are electronically offering the load to the carrier. The carrier responds with a 990 acceptance or rejection.
The 210 is the carrier's freight invoice. It details the charges for a completed shipment: base freight charge, fuel surcharge, and any accessorials. Large shippers receiving hundreds of carrier invoices per week process them via 210 rather than PDF invoices, enabling automated matching against rate confirmations and purchase orders.
The 214 provides shipment tracking updates - pickup confirmed, in transit, out for delivery, delivered. Each status update is a separate 214 transaction. Shippers and 3PLs use 214 data to drive their shipment tracking portals and customer-facing visibility tools.
The carrier's response to a 204 load tender. A "01" response code means accepted; "02" means rejected. Acceptance triggers the rate confirmation process.
The 997 is an acknowledgment that a transaction set was received and syntactically valid. Every EDI transaction should be acknowledged with a 997. It does not mean the business document was accepted - only that it was received without syntax errors. The 997 is the EDI equivalent of an HTTP 200 response, except that it arrives asynchronously, typically within minutes to hours.
The 856 is sent by the shipper to notify the consignee that a shipment is on its way. It contains detailed contents - carton count, SKU details, weight. It is used extensively in retail supply chains where the consignee's warehouse management system needs to pre-receive the shipment before the truck arrives.
EDI data is not sent over a standard HTTP connection. It travels over a VAN - a Value-Added Network. A VAN is a private network that acts as an intermediary, receiving EDI transactions from senders and routing them to receivers. Major VANs include SPS Commerce, TrueCommerce, DiCentral, and Kleinschmidt. Each trading partner (shipper, carrier, 3PL) has a mailbox on the VAN. Transactions sit in the mailbox until retrieved, typically on a scheduled polling interval - every 15 minutes to every hour.
This batch-and-poll architecture is fundamental to understanding EDI's limitations. When you tender a load via EDI 204, you don't get an instant response. The 204 goes to the VAN. The carrier's system polls the VAN, picks up the 204, processes it, generates a 990, puts the 990 in your mailbox on the VAN, and your system polls the VAN and picks up the 990. This round trip can take anywhere from 15 minutes to 3 hours depending on polling intervals.
Technical note: Some modern EDI providers offer AS2 (Applicability Statement 2) transmission, which pushes EDI directly to the trading partner's HTTPS endpoint rather than using a VAN mailbox. AS2 significantly reduces latency but requires both parties to support it. Many legacy carrier systems still use VAN-based transmission.
EDI is expensive - this is one of the primary drivers behind the industry's shift toward API-first integration. The cost structure has several components:
VAN providers charge per-transaction fees ranging from $0.10 to $0.50 per transaction set, plus a monthly platform fee. A mid-sized freight broker processing 500 loads per week might exchange 4-6 EDI transaction sets per load (204, 990, 214, 210, 997s). That's 2,000-3,000 transactions per week, or 8,000-12,000 per month. At $0.20 per transaction, that's $1,600-$2,400/month in pure transaction fees - before any setup, support, or mapping costs.
Most VANs charge a monthly fee per trading partner connection, ranging from $300 to $2,000 per month per carrier. A broker working with 20 carriers faces $6,000-$40,000/month in connection fees alone. Some VANs offer "interconnect" pricing where you connect to the VAN once and can reach any carrier also on that VAN, which reduces per-connection costs.
Before you can send a 204 to a carrier, you need an EDI map - a configuration that translates your internal data format (JSON, XML, database records) into the specific X12 format that carrier expects. Every carrier implements X12 slightly differently. The 204 transaction set has optional and required segments; each carrier specifies which segments they use and what values they accept. Building a map takes 40-80 hours of EDI developer time per trading partner. Maintaining maps as carrier requirements change is ongoing work.
A realistic EDI integration timeline for a new trading partner relationship is 3-6 months. This includes: VAN setup (2-4 weeks), map development (4-8 weeks), testing with the trading partner (4-12 weeks - carriers have their own testing requirements and queues), and go-live approval. Enterprise carriers like FedEx Freight, UPS Freight, and Old Dominion have formal EDI certification programs with defined testing phases.
Modern freight APIs use standard REST conventions over HTTPS. The request is a JSON object with your shipment data. The response is a JSON object with the carrier's data - rate quote, tracking update, BOL confirmation. Everything is synchronous: you send a request, you get a response, typically within 200-2000 milliseconds.
A load tender via REST API might look like this:
POST https://api.carrier.com/v2/loads
Authorization: Bearer {token}
Content-Type: application/json
{
"origin": {
"address": "123 Main St",
"city": "Chicago",
"state": "IL",
"zip": "60601"
},
"destination": {
"address": "456 Oak Ave",
"city": "Dallas",
"state": "TX",
"zip": "75201"
},
"pickup_date": "2026-03-10",
"commodity": "plastic injection-molded parts",
"weight_lbs": 12500,
"equipment_type": "dry_van"
}The carrier responds with a load ID, confirmation status, and assigned driver information - all within the same HTTP response, synchronously. There is no VAN, no mailbox, no polling interval. The integration is built with the same tools and patterns your engineering team uses for any other web API. You can test it with curl or Postman before writing a single line of integration code.
| Cost Category | EDI | REST API |
|---|---|---|
| Setup cost (per trading partner) | $5,000-$25,000 (mapping + testing) | $500-$5,000 (API integration dev) |
| Monthly platform fee | $300-$2,000/month per connection | $0-$500/month (API subscription) |
| Per-transaction cost | $0.10-$0.50 per transaction set | $0.001-$0.05 per API call (varies by provider) |
| Implementation timeline | 3-6 months per trading partner | 1-14 days per integration |
| Response latency | 15 minutes to 3 hours | 200ms to 2 seconds |
| Maintenance burden | High - mapping changes per partner | Low - standard API versioning |
| Error visibility | Low - async, cryptic 997 errors | High - HTTP status codes, JSON error details |
| Developer availability | Scarce - specialized EDI expertise | Abundant - standard web dev skills |
Despite its limitations and costs, EDI remains mandatory in several scenarios:
Major retailers - Walmart, Target, Home Depot, Amazon - require their carriers and 3PLs to exchange EDI. This is non-negotiable. If you are a carrier or 3PL serving these accounts, you will implement EDI. The retailer's compliance requirements specify which transaction sets are required, what data elements must be populated, and what testing you must pass before going live.
Many large shippers run TMS platforms built in the 1990s or 2000s - Oracle TMS, JDA (now Blue Yonder), Manhattan Associates TMS. These systems were designed around EDI as the primary carrier integration method. Retrofitting REST API integration into a legacy TMS is possible but often involves expensive middleware. For these environments, EDI remains the path of least resistance.
Some large national carriers - particularly in rail and ocean freight - only offer EDI integration for certain transaction types. Their API offerings cover rating and tracking but not load tendering. If you need to tender loads to these carriers programmatically and at volume, EDI may be the only option.
For a new TMS build, a freight brokerage platform, or any startup-scale company, REST API is the right default choice for freight integration. Here's why:
The freight industry's adoption of REST APIs has accelerated dramatically since 2018. Major LTL carriers now offer developer portals with documented REST APIs for rating, BOL generation, tracking, and POD retrieval. FTL capacity platforms (Convoy, Transfix, Uber Freight) were API-first from the start. The new generation of freight technology is being built on APIs.
For document generation specifically: API-based BOL and freight document generation bypasses the EDI question entirely. Rather than integrating with each carrier's EDI system to generate documents, a document generation API takes your shipment data and produces correctly formatted, compliant documents - regardless of the carrier. See our guide How to Generate a BOL via API for the technical details.
In practice, most mid-to-large freight technology companies run both. They use REST APIs for new carrier integrations, spot market transactions, and customer-facing features where real-time response matters. They maintain EDI connections for legacy accounts, retail compliance requirements, and carriers that don't offer API alternatives. A middleware layer - sometimes called an integration platform or iPaaS - handles the translation between the two paradigms.
The operational goal is to isolate EDI complexity behind an abstraction layer so that your application code only deals with clean REST APIs. The middleware handles EDI map management, VAN connectivity, and the async acknowledgment loop. Your application sends a standardized JSON request; the middleware figures out whether that request goes to a carrier REST API or gets translated to a 204 X12 transaction and dropped into a VAN mailbox.
For 3PL automation at scale, see our guide on 3PL Document Automation Integration for how to architect these workflows.
FreightDoc generates BOL, rate confirmations, carrier packets, and customs docs via API. Join the waitlist for early access.
Join the Waitlist