Carrier Connectivity: What It Means for Shippers
Carrier connectivity explained: what it is, how it differs from EDI integration, and how European shippers can judge a TMS vendor's real network.
What is carrier connectivity?
Carrier connectivity is the technical link between your transport management system and each carrier's own systems, the pipe through which tenders, bookings, tracking updates, proof-of-delivery and invoices move automatically instead of via phone, email or manual portal logins. It is not a single technology. It is an outcome, and the underlying method (EDI, API, or something messier) determines how reliable, expensive and future-proof that outcome actually is.
If you strip out the marketing language, carrier connectivity and carrier integration are near-synonyms in practice, with connectivity often used as shorthand for the same adapter layer that connects a shipper's software to a carrier's booking, tracking and billing systems. The word gets used loosely enough in vendor decks that it's worth pinning down what it isn't, before you sign a contract that assumes it means one thing when the vendor built it to mean another.
Carrier connectivity vs. EDI integration vs. carrier network
These three terms get used interchangeably in sales calls, and that's where shippers get burned. EDI integration is one method of achieving carrier connectivity, not the concept itself. A carrier network is the list of carriers you can reach, not the technical mechanism you use to reach them. And a visibility platform is one output of connectivity, not the whole system.
The clearest breakdown I've seen of how this actually works underneath the marketing comes from a framework that groups vendors into three architecture buckets. A vendor's carrier connectivity falls into one of three buckets: a direct API/EDI connection the vendor built and maintains itself; a reseller or account-layer connection where the carrier's own portal does the underlying work while the TMS wraps a UI around it; or a marketplace/freight-exchange model that brokers spot capacity rather than integrating your own contracted rates. These are not interchangeable, and a vendor that says "we integrate with 10,000 carriers" might mean any of the three.
Why does the bucket matter more than the carrier count? Because ask ten TMS vendors "do you integrate with DB Schenker, DHL, and DSV" and all ten will say yes, and that single yes/no answer is exactly why so many TMS carrier integration clauses in RFPs fail to protect buyers later, once the vendor's real connectivity model surfaces during onboarding. An account-layer connection means you're still logging rate changes and service disruptions from the carrier's own portal, just with a nicer skin on top. A direct build means the vendor owns the maintenance burden when that carrier changes its API. Ask which bucket applies to each named carrier, not which bucket applies "generally."
Why this matters more in Europe than it does in the US
Most carrier connectivity content online is written by American freight brokers describing a US truckload market dominated by a handful of large national carriers. European shippers face a different problem entirely: dozens of national and regional players (DB Schenker, DSV, GLS, DHL, PostNord, GEODIS) each running their own EDI dialect or portal, on top of rail and intermodal operators with their own booking systems again.
Layer onto that the legacy of EDIFACT messages like IFTMIN, which still underpin a lot of EU freight ordering, and the EU's ongoing push toward the eFTI regulation for electronic freight transport information, and you get a market where "connectivity" has to bridge old EDI plumbing and newer API-first carriers at the same time. A shipper running freight lanes across five or six EU countries typically deals with more distinct carrier systems than a comparable US shipper running the same freight volume through three big national carriers.
A worked example: connecting one manufacturer to four different carrier systems
Picture a manufacturer shipping FTL, LTL and parcel across DB Schenker, DSV, GLS and a regional pallet network. Each of these four connections looks completely different in practice, and that's the point.
- DB Schenker and DSV: both still run heavily on EDI for freight tendering and status messages, meaning "connected" here means an EDI mapping that pushes tender data out and pulls booking confirmations and track-and-trace events back in, without anyone touching a portal.
- GLS: increasingly API-first for parcel, so "connected" means real-time label creation and booking through a REST call rather than a file exchange, with tracking events pushed back as they happen.
- The regional pallet network: portal-only, no public API and no EDI capability, meaning true system-to-system connectivity isn't available and the fallback is a manual upload or, in the worst case, someone re-keying data by hand.
A TMS with pre-built multi-carrier connectivity is supposed to collapse all four of these into one interface, so your planners never need to know whether a given carrier speaks EDI, API or nothing at all. This is the pitch behind platforms like MercuryGate, Transporeon, Alpega and Cargoson, each aimed at shippers who don't want to run four separate integration projects to reach four carriers. Cargoson in particular positions itself around this exact gap for lean European transport teams, arguing that EDI connections are often the most convenient solution but they are very carrier-based, since each carrier has its own rules and it is expensive to establish and maintain EDI connections with all of them, which is the reasoning behind building one shared connectivity layer rather than asking every shipper to rebuild it themselves.
Parcel-heavy operations have their own version of this problem, solved by tools like Sendcloud, ShipStation and Easyship, which do for small-parcel shipping roughly what a freight-focused TMS does for FTL and LTL. If your volume is mostly parcel, that category is worth a separate look rather than forcing a freight TMS to do a job it wasn't built for.
How to evaluate a vendor's carrier connectivity before you sign
Vendor claims about carrier count are close to meaningless without knowing the architecture behind each named connection. Before signing, get specific answers to these:
- For each carrier you actually use, which of the three buckets does the connection fall into: direct API/EDI, reseller/account-layer, or marketplace?
- Who maintains the connection when that carrier changes its API or EDI spec, and is that written into the SLA rather than assumed?
- What happens to your data and your integrations if the vendor gets acquired? The TMS market is mid-consolidation, and providers realizing M&A rationale often offer an integration layer gaining access to different platforms, because end-users avoid new interfaces, meaning the end-user might not even notice they are using connectivity from various platforms consolidated through M&A over the years, which is fine until support quality or roadmap priorities shift underneath you.
- Are new carrier connections billable add-ons, and how long does the vendor commit to building one? Some vendors state they will build new integrations at no cost and typically complete them within two weeks, which is the kind of commitment worth pinning down as a contractual SLA rather than a sales claim.
| Connectivity type | Who maintains it | Typical use case | Failure mode |
|---|---|---|---|
| Direct API/EDI (vendor-built) | The TMS vendor | High-volume, long-term carrier relationships | Vendor goes quiet on maintenance after a carrier API change |
| Reseller/account-layer | Shared between vendor and carrier portal | Quick coverage for less-common carriers | You're still logging into the carrier's own system for anything non-standard |
| Marketplace/exchange | The marketplace operator | Spot capacity, not contracted rates | Doesn't reflect your negotiated rates or SLAs |
FAQ
Is carrier connectivity the same as EDI integration? No. EDI is one transport mechanism for achieving connectivity. API-based and portal-based methods also count, and most modern TMS platforms use a mix depending on the carrier.
How many carriers should a TMS connect to? As many as your actual network requires, not a headline number. A shipper running three modes across six countries needs a different connectivity footprint than a domestic parcel-only operation.
Does carrier connectivity cost extra? It varies by vendor and by bucket. Reseller/account-layer connections can carry hidden per-carrier fees; direct-built connections are sometimes bundled and sometimes billed as add-ons, so this needs to be in writing before you sign.
Who maintains the connection, the shipper or the vendor? Normally the vendor, but "normally" isn't a contract. Get it written into the SLA, especially the question of who absorbs the cost when a carrier changes its system without warning.
