Carrier Integration Software: What It Actually Is

Every vendor comparison page defines "TMS," "transport execution," and "multi-carrier shipping software" slightly differently, usually to make their own product sound broader than the next one. None of them define carrier integration software precisely, because it's not what they're selling. It's the layer underneath what they're selling.

Carrier integration software is the middleware layer that normalises requests and responses between a shipper's internal systems (ERP, WMS, OMS) and many carriers' APIs or EDI interfaces. It handles authentication, schema translation, retries, idempotency and webhook delivery. It does not plan routes, tender freight, or generate a picking list. It is infrastructure, not an application.

What carrier integration software actually does

If you strip away the dashboards and rate cards, a carrier integration layer does a small number of things, repeatedly, at scale:

• Translates one internal shipment schema into dozens of carrier-specific request formats (DHL's label API looks nothing like PostNord's, which looks nothing like UPS's).
• Manages OAuth tokens, API keys, and certificate rotation for every carrier connection, per tenant.
• Retries failed calls with backoff, without creating duplicate labels or duplicate bookings.
• Receives and de-duplicates carrier webhooks (a tracking event fired twice should not become two events downstream).
• Normalises tracking statuses so "in transit," "unterwegs," and a dozen carrier-specific codes collapse into one internal status model.

This layer is almost always invisible to the end user. A warehouse operator printing a label, or a customer checking a tracking page, never sees it. What they see is a TMS screen, an OMS order status, or a checkout widget. The carrier integration layer is the thing those systems call, not the thing anyone logs into on purpose.

What it gets confused with

TMS (transport management system)

A TMS is a planning and settlement application. Manhattan Associates describes it as "a supply chain software solution that enables enterprise-wide management, optimization, planning, and execution of logistics services for transporting goods in both inbound and outbound movement." AEB's definition adds more scope: a TMS includes transport planning and optimization, covers transport execution and supply chain visibility, includes control tower monitoring, manages freight costs including freight purchasing, and handles internal accounting and reporting.

None of that is carrier connectivity itself. A TMS decides which carrier and service level to use, negotiates rates, runs tenders, and reconciles freight invoices. It typically depends on a carrier integration layer underneath it to actually talk to the carrier's API. Some TMS vendors build that layer in-house; others license or partner it in. Either way, the TMS is the decision-maker, not the wire protocol.

Transport execution software (TES)

TES sits closer to a marketplace than to middleware. Alpega's own framing, citing ARC market research, describes global spend on "transport execution (TE) marketplaces and systems" as a distinct, measurable category, separate from planning software. TES products connect shippers to carrier networks for tendering, booking, tracking and settlement, often across thousands of vetted carriers. That's a product category a carrier integration layer powers, not a synonym for it. A TES platform still needs an integration layer to speak each carrier's actual API or EDI dialect underneath the marketplace UI.

Multi-carrier shipping software

This is the parcel-focused SaaS layer built on top of carrier integrations. nShift defines it plainly: multi-carrier shipping software "lets businesses manage shipping across multiple parcel and freight carriers from one system, including rate selection, label creation, tracking, and carrier performance reporting." Shiptify's definition is close: it "enables organizations to manage parcel shipping across multiple carriers through a centralized system," letting teams "compare transportation services, select carriers, generate labels, manage exceptions, and monitor deliveries from a single interface" instead of working through separate carrier portals.

This is the layer a warehouse operator actually clicks through. It's parcel-shaped, UI-first, and rate-shopping-aware. Underneath it, there's still a carrier integration layer doing the OAuth handshakes and retry logic for each of those carriers, whether the vendor built it themselves or bought it.

Where the boundary actually sits: a worked example

Take a real shipment flow. An ERP creates a sales order. An OMS decides how to fulfil it, then hands off to a TMS or multi-carrier tool, which picks DHL Express as the carrier and next-day as the service level based on cost and transit time rules. That decision then has to become an actual API call.

ERP ──order──> OMS ──fulfilment──> TMS / shipping app
│
(carrier + service decided)
▼
Carrier integration layer
(OAuth token, schema map,
retry on 503, idempotency key)
│
▼
DHL / PostNord / DPD API
│
(label + tracking event)
▼
◄── webhook, de-duplicated, written back ──

The carrier integration layer is the only box in that diagram that knows what a DHL 503 error means, what an idempotency key protects against, and how to collapse three duplicate tracking webhooks from PostNord into one status update. Everything above it is making business decisions. Everything at that layer is making reliability decisions.

Some products deliberately collapse two of these layers into one. Cargoson, for instance, positions itself as a hybrid, described as "a hybrid platform that balances a heavy transport management system with lightweight, multi-carrier functionality," connecting shippers to a large carrier network within a single tool. Vendors like nShift, MercuryGate, Descartes, ShipStation and Shiptify each draw the TMS/TES/carrier-integration line in slightly different places depending on their origin (freight-first vs parcel-first). That's a legitimate product strategy. It doesn't change the underlying architectural distinction: planning and execution decisions are one concern, carrier wire-protocol reliability is another.

Why the distinction matters for architects

If you buy a TMS expecting carrier-integration-grade reliability, you may be disappointed. A TMS vendor's core competency is optimisation and freight audit, not necessarily idempotent retry logic against a flaky carrier sandbox. Ask specifically how duplicate webhook delivery is handled and whether idempotency keys are exposed to you, not assumed.

If you're building carrier integration in-house, you're building infrastructure, not a shipping app. That changes the team you staff it with, the SLOs you set, and the on-call rotation you run. A carrier integration layer serving many shippers needs strict tenant isolation: one shipper's carrier credentials, rate limits, and webhook traffic should never leak into another's. A single-shipper TMS deployment simply doesn't have that problem, because there's only one tenant.

FAQ

Is a TMS the same as carrier integration software?
No. A TMS plans, tenders and audits freight; carrier integration software is the layer that actually executes the API or EDI call to a specific carrier, which a TMS typically calls rather than replaces.

Is multi-carrier shipping software just parcel-only carrier integration?
Mostly, for parcel use cases. It adds a user interface, rate shopping logic and label workflow on top of a carrier integration layer, whether that layer is built by the same vendor or licensed underneath.

Do I need both a TMS and a carrier integration layer?
For freight-heavy shippers running multiple modes, usually yes, either bought as one bundled product or integrated separately. For parcel-only e-commerce, a multi-carrier shipping platform with integration built in is often sufficient.

What's the difference between carrier integration software and EDI?
EDI is one of the protocols or message formats a carrier integration layer might speak to a given carrier. It's a wire format, not the middleware layer itself, which increasingly also has to speak REST and webhook-based APIs alongside legacy EDI.