How Logistics Platforms Should Connect to Your Tech Stack: A TMS, WMS, ERP, and OMS API Integration Guide (2026)

The integration question asked too late

Most logistics technology conversations open with protocol questions. Which carrier has the better API. EDI or REST. Both are reasonable questions and both arrive after the decision that matters.

The determining question is which systems need to exchange what, in which direction, and which layer is accountable for seeing across all of them at once.

Without an answer, the failure modes are consistent: dispatchers pulling data from three screens, order status that lags by hours, carrier assignments made on judgement rather than live capacity, and finance reconciling cost reports that never match what operations sees.

The cost of those seams is larger than most integration budgets. McKinsey estimates that inefficient logistics handovers account for 13 to 19 percent of logistics costs, as much as 95 billion dollars annually in the US alone. And capability is scarce: Gartner found 56 percent of chief supply chain officers cite integrating AI with legacy systems as a major challenge, and 50 percent report limited internal expertise to implement and manage it.

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

What each system owns

Precision here prevents most downstream argument.

TMS. Movement of freight from origin to destination: carrier selection, rate shopping, booking, and freight audit. Owns carrier contracts, lane rates, and shipment-level cost. Authoritative for what a movement costs and who is performing it.

WMS. Inventory inside the facility: what is on the shelf, pick-pack-ship workflow, and confirmation that an order has physically left. Owns inventory position, fulfilment state, and departure confirmation.

ERP. The financial and operational backbone. Owns purchase orders, vendor master data, cost centres, and reconciliation. Where delivery cost ultimately lands and where invoices match against orders.

OMS. The customer-facing layer. Receives orders from sales channels, manages lifecycle, and communicates status outward. Owns the customer order record and fulfilment priority.

One rule makes the architecture work: one system is authoritative per entity and the others reference it. Nothing should own everything. The instinct to declare one system the single source of truth for the whole order is what produces the worst architectures, because it imposes one vendor’s data model on processes it was not built for.

Why point-to-point breaks

The common mid-market pattern is direct connections: OMS to WMS, WMS to TMS, TMS to ERP, each built and maintained separately, frequently by different teams or vendors.

It works until it does not, and it fails predictably.

Sequence errors. The TMS books a carrier before the WMS has confirmed inventory, producing shipments that cannot be fulfilled.

Ambiguous status. The OMS says shipped, the WMS says pending pick, the TMS says booked. All three are partially correct at different moments, and nobody has defined which is authoritative when.

Changes that do not propagate. A cancellation in the OMS does not void the carrier booking or reverse the inventory reservation.

Blind dispatch. Without a layer seeing across what needs to move, what is ready, and what capacity exists, dispatch becomes manual coordination.

That last one is the structural gap. Gartner has found that 80 percent of the supply chain is not accounted for in current digital decision models, and point-to-point architectures are a direct contributor, because each connection carries only what the two endpoints needed.

The four integrations, specified

OMS to orchestration platform

Direction. OMS pushes order data inbound.

Minimum payload per order: order ID and line items with SKU, quantity, weight and dimensions; validated and geocoded delivery address; promised delivery window; priority flag covering standard, expedited, and same-day; and special handling requirements such as fragile, temperature-controlled, or signature required.

Pattern. Webhook or event-driven push on order confirmation. Polling introduces lag that undermines real-time dispatch.

What breaks without it. Orders reach dispatch by email or manual entry, and SLAs are applied inconsistently because priority flags never reach the routing engine.

WMS to orchestration platform

Direction. WMS pushes fulfilment confirmations; the platform queries availability.

Minimum payload on confirmation: order ID matched to the OMS record, shipment ID, actual post-pick weight and dimensions which frequently differ from order-level estimates, label generation status, and physical departure timestamp.

Pattern. Event-driven push for confirmations. API query for availability when the dispatch engine is deciding whether to commit to a window.

What breaks without it. Dispatch commits to windows based on estimated fulfilment times, and when a pick runs late the plan does not adjust, so SLA breaches accumulate invisibly.

The distinction worth building into the integration explicitly: order release and dispatch readiness are different events. Planning against release rather than readiness is the most common single cause of vehicles waiting at docks.

TMS to orchestration platform

Direction. Bidirectional, and the most complex of the four.

Inbound from TMS: available carrier services and transit estimates by lane, real-time capacity constraints including blackout periods, and rate quotes for specific shipments.

Outbound to TMS: carrier assignment with service level and tracking number request, delivery window commitment, and shipment-level routing instructions.

Pattern. API pull for rate and capacity queries, API push or webhook for assignments. Modern platforms expose REST for both; legacy platforms may require EDI or SFTP batch exchange, which introduces latency the dispatch layer then has to plan around.

What breaks without it. Dispatchers look up rates in the TMS and enter assignments in the routing tool separately, so carrier selection is slow, inconsistent, and unresponsive to live capacity.

ERP to orchestration platform

Direction. Primarily outbound. The platform reports what happened so the ERP can close cost.

Outbound payload: delivery confirmation with timestamp and proof of delivery, actual carrier cost per shipment, cost centre allocation identifying the business unit or customer account, and exception records covering failed deliveries, redelivery attempts, and returns initiated.

Pattern. Batch push or event-driven webhook depending on ERP capability. Major ERP suites support API-based ingestion for financial data, with specifics varying by module and version.

What breaks without it. Finance reconciles delivery cost manually against carrier invoices, cost-per-delivery reporting runs weeks behind operations, and exception costs never attach to the shipment that caused them.

Also Read: 5 Critical Shipping API Integration Categories for Enterprise Logistics in 2026

Also Read: Route Optimization Tools That Integrate With ERP and WMS: What to Verify Before You Buy

The EDI question

Many operators still run EDI for carrier and partner exchange, particularly in freight and 3PL relationships. It is not disappearing, and it creates a specific problem alongside REST-based orchestration.

Treat it as a translation problem rather than an architecture problem. Integration middleware or an iPaaS layer sits between EDI partners and the orchestration platform’s REST surface, handling transaction sets such as 850 purchase orders, 856 advance ship notices, and 997 functional acknowledgements, and translating them into JSON.

The consequence is that the orchestration platform does not need to speak EDI natively. It needs clean, documented REST endpoints for order ingestion, fulfilment confirmation, and carrier assignment, and the translation layer absorbs partner-specific formats. Where that middleware sits, who owns it, and who maintains the maps when a partner changes a spec are questions worth settling before implementation rather than during.

What good integration capability looks like

Six criteria for evaluating any orchestration platform on integration.

Pre-built connectors for the systems you actually run. Direct connectors to major ERP, OMS, e-commerce, and WMS platforms reduce implementation time materially against custom development. Verify which of your specific systems are pre-built versus configured, who performs the build, and who maintains it when the other vendor changes their API.

Webhook support for inbound events. The platform should receive order events, fulfilment confirmations, and status updates by push rather than requiring polling.

Documented REST API with stable endpoints. Documentation quality directly affects implementation timeline and long-term maintainability, and it is one of the few things you can assess before signing.

Idempotent writes and deduplication. Webhook delivery is at-least-once in practice. Without a deduplication key, a retried message becomes a duplicate order and then a duplicate dispatch.

Event logging and retry logic. Every inbound and outbound call logged, failures surfaced in real time, and configurable retry so a transient failure does not lose an order.

Sandbox with production parity. Every partner needs to test against non-production before go-live, and a sandbox with stubbed behaviour validates nothing.

The payoff for getting the layer right is measurable at portfolio level. Deloitte estimates that enterprises which orchestrate AI agents well could increase the value they capture by 15 to 30 percent.

Also Read: How Do IT Teams Evaluate API Integrations for Logistics Platforms?

Where Locus sits, and whether it replaces your TMS

Locus, the world’s first Decision-Intelligent, Agentic TMS, occupies the orchestration layer in the architecture above. It receives order data from the OMS, readiness and confirmation from the WMS, and carrier data from the TMS, and turns that into dispatch decisions, optimised routes, and real-time visibility for operations teams and customers.

Because Locus is itself a TMS, the obvious question is whether it replaces the one you have. The answer depends on which kind of TMS you are running, and both configurations are common.

Coexistence is correct where your existing TMS is a freight procurement and audit platform: carrier contracts, rate management, tendering, multimodal planning, and freight settlement. That platform keeps those functions and remains the commercial record, while Locus operates as the execution layer for dispatch and last-mile decisions. A Fortune 50 parcel and logistics provider took exactly this path after a replacement freight platform proved unable to run dispatch, deploying Locus as the all-mile decisioning layer alongside it and governing 4,500+ drivers under one policy while weekly execution moved from 75 percent to 92 percent.

Replacement is the usual outcome where the incumbent is a legacy execution platform doing routing and dispatch, since running two systems making the same decisions produces conflict rather than depth.

Architecturally, Locus operates as the system of execution alongside systems of record, so ERP and WMS keep data ownership and no upstream system has to change to improve dispatch. DiSCO runs eight named agents on a continuous Sense, Decide, Execute, Learn cycle, with the Dispatch agent planning and re-sequencing against 250+ real-world constraints, the Carrier agent allocating across the ShipFlex network of 160+ active carriers from 1,000+ pre-integrated partners, the Hub agent managing facility readiness, and the Settlement agent reconciling cost back to finance.

Locus has been recognized by Gartner for seven consecutive years, featured in the 2026 Hype Cycle for Supply Chain Execution and Logistics Technologies, named a Leader in TMS by QKS Group (SPARK Matrix), and ranked #1 in Route Planning on G2’s 2026 Best Software Awards. In October 2025, Ingka Investments, the investment arm of Ingka Group, the world’s largest IKEA retailer, acquired Locus. Locus continues to operate independently.

The ERP integration described earlier is the one most often deferred and most visibly missed once live. An enterprise paint leader processed 1,500+ carrier invoices a month across 160 depots entirely by hand, each moving through finance, commercial approval, and SAP entry manually with no digital trail, so audit meant pulling files. Moving settlement into one workflow with SAP-linked notifications at every step cut payment cycles from 30 to 45 days down to 7 to 10, and surfaced the 5 to 6 percent variance between transporter-claimed and contract-computed cost that manual reconciliation had been absorbing silently. That variance is the clearest illustration of what an unbuilt ERP integration costs: it was never a reporting gap, it was margin.

Also Read: How Easy Is It to Integrate Locus APIs? An Architectural Framework for Enterprise Logistics in 2026

Summary: integration requirements by system

System	Direction	Key data	Recommended pattern
OMS	Push to orchestration	Orders, line items, SLAs, priority, handling requirements	Webhook, event-driven
WMS	Push confirmations, query availability	Dispatch readiness, actual weight and dimensions, departure timestamp	Event push plus API query
TMS	Bidirectional	Carrier services, capacity, rates inbound; assignments and commitments outbound	API pull plus API push
ERP	Orchestration pushes downstream	Delivery confirmation, actual cost, cost centre, exception records	Batch push or webhook
EDI partners	Via middleware	Transaction sets including 850, 856, 997	Translation layer to REST

The pattern column is the one to argue about in design review. Anything that changes intraday belongs in the event column, and most implementations get this backwards by syncing reference data frequently and operational readiness overnight.

Where to start

The most useful first step is not a vendor evaluation. It is a data ownership audit: which system owns each entity, and where is that entity needed downstream.

From that map the integration requirements become concrete, and platform evaluation becomes a question of fit rather than of feature count. Does the platform have the connectors and API surface to act as the hub between the systems you already run, and if a connector does not exist, who builds and maintains it.

Latency deserves equal weight to connectivity. Gartner found that while 95 percent of supply chains must react quickly to change, only 7 percent can execute decisions in real time, and batch integration upstream is frequently the reason a real-time platform behaves like a scheduled one.