TMS, ERP, and WMS API Integration for Logistics: What to Look For in a Platform (2026)

What API connectivity actually means in logistics

Logistics API connectivity spans three layers that serve different purposes, and most comparison content treats them as one category.

Carrier APIs are the interfaces carriers publish for rating, booking, labels, and tracking. Each carrier defines its own authentication, schema, event vocabulary, and rate limits. Connecting to them is the problem, not the solution.

General-purpose integration middleware covers iPaaS platforms such as MuleSoft and Boomi, and EDI and B2B networks such as Cleo, TrueCommerce and SPS Commerce. These move data between systems reliably, translate formats, and manage trading partner connectivity. They are transport and translation layers, and they are domain-agnostic by design.

Logistics decisioning platforms consume that data to make operational decisions: which carrier or vehicle takes a shipment, what sequence to run, what to do when a stop runs long. Locus operates at this layer, with carrier connectivity included rather than as the product.

The distinction matters for a specific reason. Middleware answers “get this data from system A to system B.” A decisioning platform answers “given this data, what should happen next.” An operation that buys only middleware has solved connectivity and still has a person deciding, which is where the cost usually sits.

Consider the concrete case: a mid-market retailer running an SAP ERP, a third-party WMS, and five carrier contracts. Orders originate in the ERP, inventory and dock status live in the WMS, and execution happens across five carrier APIs with different schemas. Without a layer that both connects and decides, dispatch waits on someone reconciling three screens.

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.

The integration tax

Integration is budgeted as project cost and paid as recurring cost, which is why it is consistently underestimated.

McKinsey estimates inefficient logistics handovers account for 13% to 19% of logistics costs, up to roughly $95 billion in annual losses in the US alone. Every boundary between systems is a handover, and batch boundaries are the expensive ones because they add latency to every decision downstream.

The organizational side is equally documented. Gartner found 56% of chief supply chain officers say integrating AI with legacy systems and processes is a major challenge, with 50% citing limited internal expertise to implement and manage it. And Gartner reports 80% of the supply chain is not accounted for in current digital decision models, much of which is data that exists somewhere but never reaches a system that could act on it.

Deloitte finds enterprises that orchestrate AI agents well could increase the value they capture by 15% to 30%, which describes the same value pool from the opposite direction. It sits in the coordination rather than in the connections.

Also Read: TMS-WMS-ERP Integration Architecture for US Enterprises in 2026

Four integration requirements to evaluate

1. Pre-built connector coverage

The question is not how many connectors exist but which of yours are covered, productized, and maintained.

Ask which specific carriers in your network are natively integrated by name, whether your ERP and WMS connectors are productized and versioned or built per customer, who maintains a connector when the upstream system releases an update, and whether the connector covers master data as well as transactional flows.

The word connector covers a wide range of realities, from a versioned productized integration to a reference implementation to a professional services engagement. The maintenance answer predicts cost more reliably than the initial scope.

2. Real-time versus batch

Batch is not obsolete and real-time is not universally better. The distinction is whether a decision depends on the data.

Batch works for reconciliation, settlement, master data synchronization, and any exchange where the consumer acts on a schedule. It breaks when something downstream must react: dock release affecting route departure, capacity availability affecting allocation, a status change affecting a customer promise.

The failure pattern to watch for is middleware that translates batch into JSON and presents it as an API. The interface is modern and the semantics are still batch, which means the data describes a state that has already changed. The test is whether an inbound event triggers a decision or lands in a queue for the next cycle.

3. Event-driven architecture and webhooks

Polling-based integration reintroduces batch behavior with additional overhead. You learn about a change on your schedule rather than when it happens, and you pay for the requests that return nothing.

Four properties to require: provider-initiated webhooks rather than consumer polling, signed payloads so authenticity is verifiable, documented retry policy with idempotency keys, and a reconciliation endpoint so you can detect events you never received. The last one is the item teams omit and later need, because without it a missed webhook is invisible.

The systemic version of this gap is measurable. Gartner finds 95% of supply chains must react quickly to change while only 7% can execute decisions in real time. Much of that shortfall is data arriving in windows rather than in events.

4. Error handling and fallback logic

This is the requirement most often missing from evaluation criteria and most likely to cause an operational incident. The scenario to put to every vendor: a carrier API starts returning errors at 10am while you have loads mid-dispatch. What happens?

Five behaviors distinguish a resilient platform.

• Retry with idempotency. Failed requests retry without risk of double-booking a shipment, which requires idempotency keys rather than optimistic retries.

• Circuit breaking. One carrier’s outage should not stall the queue for every other carrier. Requests to the failing endpoint are shed until it recovers.

• Fallback carrier routing as policy. When a carrier is unavailable, the platform should reallocate according to rules you defined, not according to whatever the engineering default happens to be. This is a business decision that has to be configured in advance.

• Degradation with visibility. If automated handling is not possible, the platform surfaces the affected shipments as an actionable queue rather than failing silently. Silent failure is the worst outcome, because the operation discovers it from a customer.

• Reconciliation after recovery. When the carrier comes back, missed events are backfilled rather than lost, which is what the reconciliation endpoint in requirement three exists for.

Ask for a specific incident from the last twelve months and what the platform did.

Also Read: Carrier Connectivity Done Right: How Locus’s APIs Connect With Any Freight System

Platforms by integration capability

Entries are placed by layer and purpose rather than ranked, because they solve different problems. None publish standard pricing, so the “what to verify” column replaces it.

Platform	Layer	Primary strength	Decisioning included	What to verify
Locus	Logistics decisioning	Carrier connectivity plus dispatch, allocation and settlement decisions	Yes	Named coverage for your carriers, whether your ERP and WMS connectors are productized
MuleSoft	General-purpose iPaaS	API management and integration at enterprise scale, domain-agnostic	No	Whether logistics-specific logic must be built by you on top
Boomi	General-purpose iPaaS	Cloud integration and data management across applications	No	Same, plus logistics connector availability
Cleo	EDI and B2B integration	Supply chain EDI, trading partner onboarding, format translation	No	Real-time API alongside EDI, and whether decisioning is expected elsewhere
TrueCommerce	EDI and B2B network	Retail supplier trading partner connectivity and compliance	No	Coverage of your specific trading partners and carriers
SPS Commerce	Retail EDI network	Large retail trading partner network and onboarding	No	Non-retail carrier and freight connectivity
Descartes	Logistics platform	Customs and trade compliance plus carrier network connectivity	Partial	Which specific modules cover your modes and flows

Reading the “decisioning included” column is the point of the table. Five of the seven are transport and translation layers, which is what they are designed to be. An operation that selects one of those has solved data movement and still needs a layer that decides, whether that is a platform, a custom build, or a person.

The corollary matters too. If your problem is genuinely trading partner connectivity with a large retailer, an EDI network is the right answer and a decisioning platform is not a substitute for it. Many enterprises need both.

How Locus connects TMS, ERP, and WMS

Locus operates as the decisioning layer above the estate. ERP and WMS remain systems of record; Locus operates as the system of execution.

The flow, in sequence:

• Order intake. Orders and their attributes arrive from the ERP or OMS through documented REST APIs, or as partner-mandated EDI translated into internal events on arrival rather than staged for the next cycle.

• Constraint resolution. The Dispatch Agent resolves the order against 250+ real-world constraints modeled per computation, including vehicle class, time windows, capacity, certification requirements and access restrictions, expressed as the customer’s own business rules.

• Capacity and carrier decision. The Capacity Agent evaluates available capacity across owned, contracted and gig pools while the Carrier Agent holds every carrier contract and rate structure as the live source of truth, allocating per shipment across 1,000+ pre-integrated carriers on cost, SLA, ETA and serviceability.

• Warehouse coordination. The Hub Agent consumes dock and readiness state so release timing and route departure are one coordinated decision rather than two independent ones.

• Execution and normalization. Carrier execution events return and are harmonized into one standard status set before reaching any downstream system, which is what makes cross-carrier comparison valid rather than merely combined.

• Customer layer. The Customer Agent tracks each order against its promise with branded tracking, proof of delivery and alerts when a commitment is at risk.

• Settlement. The Settlement Agent reconciles invoices against planned versus executed cost and posts results back to the ERP.

Six governance mechanisms, Explainability, Traceability, Evaluation, Autonomy Levels, Execution Sandbox and Human-in-the-Loop, make each automated decision reconstructable.

What to verify with us, as with anyone. Which of your specific carriers are natively covered, whether your ERP and WMS connectors are productized or would be built for your implementation, and the measured latency from an inbound event to a dispatched decision.

Also Read: How Enterprises Migrate from Legacy Transportation Management Systems to AI-Native Architecture

Deployment evidence

Integrating into a legacy estate: a Fortune 50 parcel and logistics provider. This operator runs one of the world’s largest multimodal freight forwarding networks across air, ocean and ground, moving 1M+ freight shipments a year across a 120-country footprint. The integration surface was the hard part rather than the routing. The decisioning layer had to connect securely into a replacement freight platform, into legacy systems covering information security, customs, timecard and labor, and into live traffic, location and regulatory feeds, while governing a 4,500-strong driver pool split across roughly 1,500 captive and 3,000 third-party drivers.

Orchestrator and Dispatch agents took over pickup, transit and delivery decisioning against 250+ operational constraints, with Capacity and Carrier agents governing the full driver pool under one policy. Weekly execution rate moved from 75% to 92% across 51 active service-center locations, with 1M+ freight shipments a year running on one decision layer at 99.99% platform uptime. Detail in the Fortune 50 parcel centralized dispatch case study.

Note what did not happen. Customs, timecard, labor and information security systems were not replaced. Their data reached a layer that could act on it, which is the realistic shape of integration in an enterprise with an established estate.

Six systems to one decision layer: a leading North American retailer. This retailer supplies a multi-hundred-store footprint through several distribution centers and hubs, with a private fleet of several hundred trucks alongside 3PL capacity. It ran on six disconnected systems that could not scale without adding headcount. Planning ran leg by leg rather than as one system, loads and freight bills were handled manually, and nothing tracked freight 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 transit, and Settlement agents automate freight billing and reconciliation. Results: 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, 80%+ reduction in manual dispatch, and $1M+ in savings with break-even inside the first year. Detail in the multimodal logistics automation case study.

The six-to-one consolidation is the integration case in its clearest form. The systems were not the problem individually; each worked. The seams between them were.

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.

Decision framework

Three questions resolve most platform selections.

How many systems need to connect, and do they need to decide or only exchange? If the requirement is moving data between a fixed set of systems on a schedule, middleware is sufficient and cheaper. If a change in one system should alter what happens in another, you need a decisioning layer.

Do you need real-time event triggers or scheduled synchronization? Reconciliation, settlement and master data tolerate batch. Dispatch, allocation and customer promises do not. Most enterprises need both, which makes the boundary design the actual decision.

Also Read: Carrier Management Software: How to Manage Multi-Carrier Logistics at Scale

Is your priority carrier flexibility or ERP depth? Carrier flexibility favors platforms with large pre-integrated networks and per-shipment allocation. ERP depth favors vendors with productized connectors to your specific ERP version, maintained by them. Very few excel at both, so establish which failure would hurt more.