Do Digital Freight Marketplaces Still Use EDI?
Digital freight marketplaces like Uber Freight still run EDI 204/990/214 tenders alongside APIs. See when shippers and carriers need each for booking.
Yes. If a carrier has an EDI (TMS) integration with Uber Freight, that counts as a source of automated tracking for larger fleets, and carriers who want one can email Uber's freight-solutions team to explore it. Uber Freight itself says its TMS, API, and EDI connections let carriers submit bids, schedule appointments, update status, and manage documents from their existing systems. EDI didn't disappear on digital freight marketplaces. It sits right next to the API layer, doing the work APIs still can't reach for most of the carrier fleet.
What EDI transactions does Uber Freight actually support?
The core cycle is the same four transaction sets that have run truckload freight for two decades: EDI 204, 990, 214, and 210. Orderful's trading partner page for Uber Transplace lists x12 210 (Motor Carrier Freight Details and Invoice), x12 990 (Response to a Load Tender), x12 214 (Transportation Carrier Shipment Status Message), and x12 204 (Motor Carrier Load Tender) as the document types required to trade with the platform.
Each one does a specific job in the tender-to-pay cycle:
- EDI 204 is the load tender the shipper or broker sends to offer a shipment to a carrier, including shipping instructions, schedule details, equipment requirements, and commodities.
- EDI 990 is the carrier's accept, reject, or counter response to that tender.
- EDI 214 carries shipment status updates, sending time, date, location, route, identification numbers, and conveyance back to the shipper and other parties.
- EDI 210 closes the loop with the carrier's freight invoice.
If you've mapped this cycle for any other broker or 3PL, you've mapped it for Uber Freight too. There's nothing marketplace-specific about the transaction set itself, only about who's on the other end of the connection.
Why does an API-first marketplace still run EDI at all?
Because most of the carrier base it needs to book freight was never going to rebuild its dispatch and billing systems around a marketplace's API. Uber Freight has been public about pushing APIs hard, including a scheduling API pilot built to the Scheduling Standards Consortium's technical standard. But the reason that consortium exists is telling: its members explained that trucking still relies largely on EDI or even manual methods to share data when scheduling the movement of freight, and that there's been a bigger push lately into using application programming interfaces precisely because scheduling has stayed the most fragmented, least-automated part of the shipment lifecycle.
Read that carefully and the picture is clear: the API push is a response to an EDI-entrenched status quo, not proof that EDI has been replaced. Visibility layers like project44 and FourKites sit on top of this same data, often ingesting EDI 214 feeds and re-serving them as clean API responses to shippers who never touch the underlying X12 segments themselves.
Should a shipper connect to freight marketplaces via EDI or API?
It depends entirely on your carrier mix, not on which connection method feels more modern. Enterprise LTL and FTL carriers still run EDI-based TMS platforms internally, so tendering to them through EDI 204/990 is usually the path of least resistance. Digital-native capacity, small carriers, and spot bidders are more likely to live in a portal or app, where an API integration (or the platform's own UI) is the only realistic option.
| Carrier type | Typical connection | Why |
|---|---|---|
| Enterprise LTL/FTL carrier | EDI 204/990/214/210 | Dispatch and billing already run on TMS platforms built around X12 |
| Regional or small carrier | App, web portal, or REST API | No in-house TMS to maintain an EDI VAN/AS2 connection |
| Digital brokerage / spot capacity | API | Built for real-time bid, book, and track without batch file exchange |
A platform trying to book against all three needs an integration layer that speaks both protocols fluently, not a REST wrapper bolted onto a legacy EDI mapper. That's the gap that TMS vendors with native multi-protocol carrier connectivity are built to close, and it's worth checking how a shortlist of vendors actually models that split before you sign. Analysis of eight TMS platforms found three distinct architectures hiding behind the word "integration": direct API/EDI, reseller account, and marketplace connectivity, each with a different cost, maintenance burden, and failure mode. Enterprise multimodal suites like MercuryGate and Descartes trade higher cost for broader modal coverage, network models like Transporeon and Alpega give you reach you didn't build yourself, and shipper-focused platforms such as Cargoson prioritize direct ownership of a smaller, negotiated carrier list so you're executing your own contracted rates rather than someone else's network.
Do small carriers need EDI to bid on marketplace loads?
No, not for spot bidding. Uber Freight's own guidance is that it prefers carriers use the Uber Freight app, web portal, ELD integration, or third-party data aggregators since they provide the most real-time visibility to shippers. A one-truck operator chasing spot loads doesn't need an AS2 connection or a VAN subscription to compete on that freight.
Contract freight is a different story. Large shippers and brokers building long-term lanes increasingly expect carriers to plug into their existing EDI cycle, because that's how tender acceptance, status updates, and invoicing already flow for the rest of their network. For a small carrier, EDI capability stops being a nice-to-have the moment it wants recurring, non-spot volume rather than one-off bids.
How does this affect TMS and carrier connectivity decisions?
Audit your carrier mix before you audit vendor feature lists. Count how many of your top 100+ partners run EDI-native TMS platforms versus API-first or app-based operations, then ask every vendor on your shortlist a direct question: do you support AS2/VAN EDI and REST APIs natively, or is one of them handled through bolt-on middleware you'll be debugging in six months?
For freight-specific connectivity, that shortlist typically includes MercuryGate, Descartes, Transporeon, Alpega, Uber Freight, and Cargoson. If you're also managing parcel alongside freight, add multi-carrier parcel players like ShipStation, Sendcloud, or Shippo to the comparison, since smaller shippers often need both freight-grade EDI and parcel-grade API in the same stack. None of this makes EDI obsolete. It just means the connectivity decision is about matching protocol to counterparty, not picking a winner between two technologies that are going to keep coexisting for years yet.
