General
The 3PL Integration Stack: How to Connect TMS, WMS, ERP, and Carrier APIs in 2026
Key Takeaways
- A 3PL integration stack spans four layers: TMS for routing and dispatch, WMS for warehouse execution, ERP for billing and inventory, and carrier APIs for shipment execution.
- Integration depth is a commercial capability rather than a technical one, because client onboarding speed determines which business a 3PL can bid for.
- The TMS and WMS boundary is where visibility failures concentrate, since dock release timing determines route departure while each system optimizes a different objective.
- Contract logistics runs on thin margins, with public filings showing GXO at a 1.9% operating margin on $11.7 billion of revenue, so platform-driven efficiency is the margin rather than an improvement to it.
- McKinsey estimates inefficient logistics handovers account for 13% to 19% of logistics costs, and a four-layer stack integrated point-to-point maximizes the number of handovers.
What a 3PL integration stack has to cover
A 3PL integration stack has to connect four layers: a TMS holding routing and dispatch decisions, a WMS running warehouse execution, an ERP carrying billing and inventory, and carrier APIs executing shipments. The requirement is not that all four exist but that events propagate between them fast enough for decisions in one layer to reflect current state in the others.
The distinction that matters in evaluation is between connectivity and orchestration. Most 3PLs can move data between all four layers. Far fewer can act on a change in one layer by re-deciding in another, which is the capability shippers are actually testing when they ask about integration depth.
Outsourcing scale makes this a large commercial question. Armstrong & Associates reports the global 3PL market approaching $1.3 trillion in 2025, with 94% of domestic Fortune 500 companies working with at least one 3PL, up from 46% in 2001. Integration capability is increasingly what differentiates providers in that market, because the operational services have converged.
Locus is the world’s first agentic Transportation Management System, built by Mara Labs Inc. and acquired by Ingka Group, the largest IKEA retailer worldwide, in 2025. Locus has supported 1.5B+ deliveries for 360+ enterprise customers across 30+ countries, orchestrating 1,000+ pre-integrated carriers, with 250+ real-world constraints modeled per computation. Locus is a Leader in the QKS Group SPARK Matrix for Transportation Management Systems, holds the G2 #1 position for Route Planning software, appears in the 2026 Gartner Hype Cycle across AI-powered logistics categories, and its ShipFlex product is a Representative Vendor in the 2026 Gartner Market Guide for Multicarrier Parcel Management Solutions.
The four layers, and what each owns
| Layer | Owns | Key data it must publish | Key data it must consume |
|---|---|---|---|
| TMS | Routing, sequencing, dispatch, carrier allocation | Planned route, assigned capacity, departure requirement, executed cost | Order attributes, dock readiness, inventory availability, carrier serviceability |
| WMS | Picking, staging, loading, dock scheduling | Pick completion, staging status, dock release, load contents | Route plan, departure time, sequence, load requirements |
| ERP | Billing, inventory master, client contracts | Client rates and contract terms, inventory positions, invoice status | Executed movements, proof of delivery, accessorial events |
| Carrier APIs | Shipment execution, tracking, labels, rating | Status events, exception reasons, delivered confirmation, rated charges | Tender, booking, label request, serviceability query |
Reading the table by column rather than by row is what exposes the design requirement. Almost every item in the consume column of one layer appears in the publish column of another, and each of those pairings is a coupling that either happens in real time or accumulates latency.
Why integration depth defines 3PL competitiveness
Integration depth shows up in three commercial places, none of which is a technology line item.
Client onboarding speed determines which business you can bid for. A 3PL that needs an engineering project per client integration cannot compete for short-cycle business, seasonal contracts, or pilots that convert. Onboarding time is therefore a sales constraint expressed as an IT metric.
Integration quality determines whether you can prove SLA performance. A client asking for evidence of on-time performance is asking whether your stack produced a defensible record. Data assembled after the fact from four systems invites dispute; a single executed-versus-planned record does not.
Platform efficiency is the margin. Contract logistics operates on thin margins: public filings show GXO posting a 1.9% operating margin on $11.7 billion of revenue in 2024, with DHL Supply Chain around 6%. At those levels, integration inefficiency is not absorbed by the provider’s margin because there is very little margin to absorb it with.
The recurring cost of the gaps is quantified. McKinsey estimates inefficient logistics handovers account for 13% to 19% of logistics costs, up to roughly $95 billion annually in the US. A four-layer stack wired point-to-point creates the maximum number of handovers, since each pair of layers requires its own translation.
The TMS and WMS boundary, where visibility failures concentrate
This boundary deserves separate treatment because it is where most order visibility failures originate, and the mechanism is structural rather than accidental.
A route plan assumes a departure time. Departure depends on dock release. Dock release depends on pick completion, staging, and loading, all governed by the WMS with a different objective function. When the WMS optimizes for pick efficiency and the TMS optimizes for route efficiency, both succeed locally and the departure slips.
A slipped departure is not a proportional delay. It compounds: later departure means worse traffic, tighter downstream windows, higher probability of recipient unavailability, and less slack to absorb a second disruption. A twenty-minute dock delay can invalidate a route plan.
Three requirements follow. Dock and yard state must reach the routing layer as live signals rather than shift-end reports. Route construction must treat realistic release time as a constraint rather than an assumption. And when release slips, the system must re-decide the route rather than dispatch the original plan late.
The reciprocal failure is dwell at the receiving end, and it is measurable. ATRI found drivers detained at 39.3% of all stops in 2023, losing between 117 and 209 hours per year depending on sector, at a cost of $3.6 billion in direct expenses and $11.5 billion in lost productivity. Every one of those hours is a coordination failure between a facility and a vehicle.
The TMS and ERP boundary
This boundary carries the money, and the integration requirement is narrower but less forgiving.
Three flows matter. Client contract terms and rates have to reach the layer making allocation decisions, or the 3PL optimizes against list rates rather than against what the client is actually charged. Executed movements and proof of delivery have to reach billing, or invoices are raised against plan rather than execution. And accessorial events have to be captured at the point they occur, since reconstructing them later is the most common source of unbilled revenue in 3PL operations.
On named connectors, a practical caution for evaluation. Vendors commonly list ERP connectors for major platforms, and the label covers a wide range of realities, from a productized versioned connector to a reference implementation to a services engagement. Ask which specific version is supported, whether the connector is productized or built per client, who maintains it when the ERP releases an update, and whether it covers both master data and transactional flows. The answer to the maintenance question is the one that predicts cost.
The carrier API layer
The carrier layer sits above the TMS in decision order and below it in execution order, which is a distinction worth being precise about.
The TMS decides which carrier should take a shipment. The carrier API executes that decision and reports back. What matters at scale is that allocation is decided per shipment against live serviceability, rates, and performance rather than per lane against a rate card, and that returning status events are normalized into one standard set so client-facing reporting does not vary by which carrier drew the parcel.
Two carrier-layer capabilities have direct commercial consequence for a 3PL. Onboarding time for a new carrier determines how fast capacity can be added during a surge. And status normalization determines whether client SLA reporting is defensible across a mixed carrier network.
Also Read: Carrier Management Software: How to Manage Multi-Carrier Logistics at Scale
Evaluation checklist: 3PL integration readiness
Score each item 0 for absent, 1 for partial, 2 for productized. A shipper can apply this to a prospective 3PL, and a 3PL can apply it to itself.
| # | Capability | 0 | 1 | 2 |
|---|---|---|---|---|
| 1 | Dock or yard state reaches the routing layer | Shift-end reports | Periodic sync | Live events |
| 2 | Route re-decided when dock release slips | Manual | Alert only | Automatic re-plan |
| 3 | Client contract terms available to allocation logic | List rates only | Manual lookup | Live contract as source of truth |
| 4 | Billing raised against executed rather than planned movements | Plan-based | Post-hoc reconciliation | Executed-cost audit before invoice |
| 5 | Accessorial events captured at occurrence | Reconstructed later | Partially captured | Captured at event |
| 6 | Carrier allocation decided per shipment | Per lane rate card | Rules-based | Live cost, SLA, serviceability |
| 7 | Carrier status normalized to one standard set | Per-carrier codes | Partial mapping | Single normalized set |
| 8 | New carrier onboarding time | Months | Weeks | Days |
| 9 | New client onboarding is configuration, not engineering | Custom build | Templated build | Configuration |
| 10 | Client-specific rules, SLAs, and reporting isolated per tenant | Shared config | Partial isolation | Full multi-tenancy |
Scores above 15 indicate an orchestrated stack. Scores between 8 and 15 indicate connectivity without orchestration, which is the most common state. Below 8, integration is a manual process wearing an API.
Also Read: TMS-WMS-ERP Integration Architecture for US Enterprises in 2026
Why point-to-point integration underperforms an orchestration layer
Wiring four layers point-to-point requires up to six connections, each with its own translation, error handling, and failure mode. Adding a fifth system does not add one connection; it adds four.
The deeper problem is that point-to-point integration moves data without moving decisions. Dock release reaching the TMS as a data field is not the same as dock release triggering a re-plan. The first is connectivity. The second is orchestration, and it is what the checklist above is actually measuring.
Deloitte finds enterprises that orchestrate AI agents well could increase the value they capture by 15% to 30%. Read alongside the McKinsey handover figure, the two describe the same value pool from opposite sides: it sits in the coordination rather than in the individual systems.
Gartner also reports 80% of the supply chain is not accounted for in current digital decision models. For a 3PL, much of that missing 80% is data that already exists inside one of the four layers and never reaches a system that could act on it.
How Locus connects the stack
Locus operates as the decisioning layer above the four layers rather than as a replacement for them. ERP and WMS remain systems of record. Locus operates as the system of execution, connecting through documented REST APIs and webhooks, and consuming partner-mandated EDI where trading relationships require it.
Eight agents divide the decision space and share one constraint model, one policy layer, and one audit trail. The Hub Agent runs DC, yard, and hub operations, outbound readiness, and carrier handoff as a single chain of custody, which is the agent that closes the TMS and WMS boundary. The Dispatch Agent plans, sequences, and re-sequences against live signals. The Capacity Agent forecasts demand and right-sizes fleet and roster. The Carrier Agent holds every carrier contract and rate structure as the live source of truth and allocates per shipment across 1,000+ pre-integrated carriers. The Customer Agent tracks each order against its SLA and normalizes carrier status into one set. The Settlement Agent audits invoices against planned versus executed cost, which is the ERP boundary requirement. The Orchestrator Agent coordinates across agents and surfaces where a process has stalled, and Mycroft AI Co-Pilot provides natural-language access to the decisioning.
Six governance mechanisms, Explainability, Traceability, Evaluation, Autonomy Levels, Execution Sandbox, and Human-in-the-Loop, keep decisions auditable, which is what allows a 3PL to defend a cost allocation or an SLA claim to a client.
Also Read: How 3PL CFOs Can Quantify the ROI of Dispatch Automation
Deployment evidence: consolidating a multi-layer stack
Six systems to one decision layer: a leading North American retailer. This operation supplies a multi-hundred-store footprint through several distribution centres and a network of hubs, with a private fleet of several hundred trucks moving tens of thousands of deliveries a year across ocean, rail, and road, alongside 3PL capacity. It ran on six disconnected systems that could not scale without adding headcount. Routing followed fixed patterns while loads, appointments, and freight bills were handled manually. Planning ran leg by leg rather than as one system, so trailers went out underfilled and return legs ran empty. Freight moved across ocean, rail, DC, hub, and store with nothing tracking it end to end, so exceptions surfaced only after delays reached store service.
On Locus, Dispatch agents run routing across DC, hub, and last-mile against 250+ operational constraints, the Hub agent orchestrates DC, yard, and ocean and rail transit, Capacity and Carrier agents plan loads and match backhaul, and Settlement agents automate freight billing and reconciliation. Results: $1M+ in savings with break-even inside the first year, six legacy systems replaced by one agentic TMS, 100% real-time visibility across truck, rail, and 3PL, 99%+ on-time store delivery with exceptions resolved in under two hours, 95%+ route compliance, and 80%+ reduction in manual dispatch, inside a six to nine month kickoff-to-go-live window. Detail in the multimodal logistics automation case study.
The trailer utilization detail is the clearest illustration of the point-to-point problem. Underfilled outbound and empty return legs were not a routing failure. They were a planning-in-isolation failure, visible only once one system held both legs.
Multi-market stack with automated verification: a global food and beverage leader. This operation runs one of the largest F&B distribution networks across Southeast Asia and MENA, serving 150,000+ retail outlets, with 100+ distribution centers, 33+ cities, and 5,000+ vehicles dispatched monthly in its largest market. Routes were built manually on informal logic that ignored real constraints. Transporter management was handled market by market with no consistent way to compare rates. SLAs were tracked manually with no alerts. Proof of delivery was verified by hand, so disputes surfaced after the fact. Invoices were reconciled manually against contracts.
The Dispatch Agent now plans and sequences every route against 250+ live constraints modeled as the customer’s own business rules, the Capacity Agent forecasts demand and right-sizes the fleet, the Carrier Agent scores every transporter on cost and service with competitive trip bidding, the Hub Agent runs hub and multi-leg movements as one chain of custody with AI-verified proof of delivery, and the Settlement Agent audits every invoice against planned versus executed cost. Results across six markets: 97%+ SLA adherence, 18M+ orders planned per year, 22% reduction in procurement costs, 15% improvement in rider time efficiency, and approximately 90% of proof-of-delivery reviews automated. Detail in the global FMCG logistics automation case study.
The 90% POD automation figure maps directly to checklist items 4 and 5. Verification stopped being a back-office task performed after the fact, which is what decoupled review workload from volume.
Analyst validation
QKS Group names Locus a Leader in its SPARK Matrix for Transportation Management Systems. G2 ranks Locus #1 for Route Planning software. Locus appears in the 2026 Gartner Hype Cycle across AI-powered logistics categories. ShipFlex is named a Representative Vendor in the 2026 Gartner Market Guide for Multicarrier Parcel Management Solutions. Gartner has recognized Locus for seven consecutive years. The full set is at Locus analyst recognition.
Five questions a shipper should ask a 3PL
Five questions separate an orchestrated stack from a connected one.
- When a dock release slips by thirty minutes, does anything other than a person change the route?
- Are my contract rates available to your allocation logic as a live source of truth, or looked up manually?
- Is my invoice raised against planned cost or against executed cost, and can you show the audit?
- How long does it take you to onboard a new carrier, and is that a technology constraint or a commercial one?
- Are my business rules, SLAs, and reporting isolated from your other clients, and can you demonstrate that?
Frequently Asked Questions (FAQs)
What APIs do 3PLs need?
A 3PL needs API connectivity across four layers: TMS for routing and dispatch decisions, WMS for warehouse execution including dock and yard state, ERP for client contract terms and billing, and carrier APIs for tender, labels, rating, and status events. The requirement is that events propagate fast enough for a change in one layer to be reflected in decisions made in another.
How do I evaluate a 3PL’s tech stack?
Score ten capabilities across the four layers, from whether dock state reaches the routing layer as live events through to whether client rules and reporting are isolated per tenant. Score each 0 for absent, 1 for partial, and 2 for productized. Above 15 indicates orchestration, 8 to 15 indicates connectivity without orchestration, which is the most common state.
What is the difference between TMS and WMS APIs?
A TMS publishes route plans, capacity assignments, departure requirements, and executed cost, and consumes dock readiness, inventory availability, and carrier serviceability. A WMS publishes pick completion, staging status, dock release, and load contents, and consumes route plans and departure times. The two are complements, and the boundary between them is where most order visibility failures originate.
Why is the TMS and WMS integration the most common failure point?
Because both systems succeed at their own objective and the coordination between them is unowned. The WMS optimizes pick efficiency, the TMS optimizes route efficiency, and the departure time neither controls determines whether the route is viable. A twenty-minute dock delay compounds rather than delays, because later departure means worse traffic and tighter downstream windows.
How should ERP connectors be evaluated?
Ask which specific ERP version is supported, whether the connector is productized and versioned or built per client, who maintains it when the ERP releases an update, and whether it covers master data as well as transactional flows. The maintenance answer predicts cost more reliably than the initial build scope, and the word connector covers a very wide range of realities.
Does integration depth actually affect 3PL margins?
Materially, because there is little margin to absorb inefficiency. Public filings show GXO at a 1.9% operating margin on $11.7 billion of revenue in 2024, with DHL Supply Chain around 6%. McKinsey separately estimates inefficient logistics handovers account for 13% to 19% of logistics costs, which is a large multiple of the available margin.
Is point-to-point integration ever the right choice?
For two layers with a stable, narrow interface, it can be. It degrades as layers are added, because each new system requires a connection to every existing one, and because moving data between systems is not the same as re-deciding in one system when another changes. The test is whether an event triggers a decision or populates a field.
What does multi-tenancy actually require?
Client separation at the data layer, client-specific business rules and SLAs, client-specific rate structures, client-facing reporting, and cost attribution defensible per client on co-mingled routes. Platforms that assume a single shipper identity force a 3PL into parallel instances or shared configurations, both of which cost margin and neither of which is fixable by configuration later.
General
EDI vs. API Integration in Logistics: What to Use, When, and Why it Matters in 2026
Aug 13, 2026
When to use EDI, when to use APIs, and why enterprise logistics operations run both. Covers X12 and EDIFACT transaction sets, event-driven architecture, and hybrid integration patterns.
Read more
General
Last-Mile Delivery in 2026: What Drives the Cost, Which Challenges Compound It, and How High-Volume Operations Fix it
Aug 13, 2026
What actually drives last-mile delivery cost in 2026, why most of it originates before the vehicle leaves the hub, and the five fixes high-volume operations apply to bring it under control.
Read moreInsights Worth Your Time
The 3PL Integration Stack: How to Connect TMS, WMS, ERP, and Carrier APIs in 2026