API Integrations and Systems Connectivity: Ten Things to Verify When Onboarding a Dispatch Management Platform

Why onboarding fails differently from selection

A vendor evaluation asks whether a platform can do the work. An onboarding project asks whether your data, your systems, and your team can support it doing the work, and those are different questions with different failure modes.

Selection failures are visible: a capability was missing, a constraint could not be modelled, a connector did not exist. Onboarding failures are quieter. The integration passes testing and produces subtly wrong behaviour in production because a field was mapped to the nearest available equivalent rather than the correct one. A credential expires eleven months after go-live and nobody is notified. An outbound flow was scheduled for phase two and phase two never happened.

The capability to absorb these is scarcer than most plans assume. Gartner found that 56 percent of chief supply chain officers cite integrating with legacy systems and processes as a major challenge, and 50 percent report limited internal expertise to implement and manage it. Onboarding is where that gap becomes a schedule.

The ten checks below are for the project rather than the shortlist. Each is something to verify before a stage completes, not something to ask a vendor before signing.

Also Read: The Dispatch Platform Onboarding Checklist: 10 Questions for Enterprise Leaders in 2026

The ten checks

1. Master data reconciled before the first interface is built

Locations, carriers, customers, products, and service levels matched across every system that will exchange them. Not documented as an intention, actually reconciled, with a named owner for each entity and a process for handling new records.

This sits first because it is the only item on this list that cannot be fixed later without redoing work. Every interface built on unmatched location identifiers inherits the mismatch, and the symptom is permanent manual reconciliation that nobody can trace to a cause.

The evidence for doing it properly is direct. A US home care provider ran three systems in isolation, with schedulers keying every appointment three times and mismatched patient identifiers producing duplicate and orphaned records. Identity normalisation ended the duplicates, with changes then propagating across all three systems in under 10 seconds and integration reliability above 99 percent, meaning under 1 percent failure across the three.

2. Dispatch readiness distinguished from order release

The most common single field-mapping error in this category. Order release means work has been sent to the floor. Dispatch readiness means a consignment is physically staged and loadable. They are different events, sometimes hours apart.

Mapping release to the readiness field produces plans built against a time that has not happened, and the consequence is vehicles waiting at docks for loads still being picked. It is a mapping decision rather than a technical limitation, which is exactly why it survives into production so often.

3. Idempotency and deduplication keys agreed per endpoint

Webhook delivery is at-least-once in practice, not exactly-once. Without a deduplication key, a retried message becomes a duplicate order, and a duplicate order in a dispatch platform becomes a duplicate dispatch.

Verify which endpoints are idempotent, what the deduplication key is for each, and what the system does when it receives the same event twice. Test it by sending the same event twice.

4. Event time and processing time handled separately

A fix or a status generated at 14:12 and received at 14:19 is evidence about 14:12. If the receiving system treats it as current state, the shipment or the vehicle jumps backwards, and the plan built on it is wrong in a way that is very hard to debug after the fact.

This matters most with offline replay from driver devices, where out-of-order arrival is normal rather than exceptional.

5. Sandbox loaded with production-representative data

A sandbox tested with twelve clean orders validates nothing. Load it with a real operating day, including the awkward cases: partial picks, address records that fail validation, an order cancelled after release, a carrier rejection.

Ask specifically whether sandbox carrier responses are live or stubbed. Integrations that pass against stubs fail on the first real peak.

6. Credential and certificate ownership assigned, with expiry alerts

Every integration authenticates, and every credential eventually expires or rotates. Assign a named owner per interface, record the expiry date, and set an alert with enough lead time to act.

Integrations built by a project team and handed to nobody are the most common cause of unexplained outages twelve to eighteen months after go-live, by which time the people who built them have moved on.

7. Failure behaviour defined per interface before go-live

For each interface: what happens when it fails, how the failure surfaces, who is notified, and what the operation does in the interim.

Defining this after the first outage means defining it under pressure, and the answer arrived at then is usually worse. The specific question worth forcing is what the dispatch layer does when an inbound feed stops: continue on last-known state, halt planning, or degrade to a defined fallback. All three are defensible and only one should be a surprise.

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

8. Outbound flows built, not deferred

Inbound integrations get built because nothing works without them. Outbound flows, dispatch confirmation, ETAs, exception events, and proof of delivery returning to the systems of record, get scheduled for a later phase and frequently stay there.

The consequence is that finance reconciles manually, customer service works from stale state, and the rest of the business operates from a different reality than operations. Since the seams between systems are where cost accumulates, this is expensive: 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.

A leading ASEAN apparel retailer shows the outbound side done properly: every carrier’s status harmonised into one standard set and synced back to the retailer’s OMS and WMS, giving operations control tower visibility across every last-mile shipment, alongside label and shipment creation at packing in under 500 milliseconds.

9. A reconciliation report for the parallel run

During parallel running, something has to compare what the old system did against what the new one would have done, at record level rather than in aggregate.

Aggregate comparison hides the cases that matter. A day where both systems produced 400 dispatches looks like agreement and may contain 40 differences. Build the reconciliation before the parallel run starts, because building it during means running blind through the period designed to find problems.

10. Rollback tested, not documented

Every implementation plan contains a rollback path. Few have exercised it.

The questions to answer by test rather than by document: what happens to in-flight messages, whether the previous system can accept status for work dispatched by the new one, how long reversion takes, and who authorises it. Run it once in the sandbox with production-representative volumes.

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

Sequencing the ten

Order matters, because several of these cannot be corrected later.

Before any build: master data reconciliation, field mapping decisions including readiness versus release, and credential ownership assignment.

During build: idempotency and deduplication per endpoint, event time handling, sandbox data loading, and failure behaviour definition.

Before parallel run: outbound flows and the reconciliation report.

Before cutover: rollback tested.

The two most commonly deferred items, outbound flows and rollback testing, are both scheduled late and both cheap to do early. Deferring them is a decision worth making explicitly rather than by omission.

What this protects against

Project failure in this category is rarely technical. Gartner predicts that more than 40 percent of agentic AI projects will be cancelled by the end of 2027, attributing this to escalating costs, unclear business value, and inadequate risk controls rather than to capability. Escalating costs in an integration project usually means rework, and rework usually traces to one of the first three items on this list.

Timeline pressure makes the discipline harder and more valuable. A Gartner-commissioned analysis indicates more than 40 percent of TMS adopters break even within 6 to 12 months, which is the window most business cases assume. Rework from unreconciled master data is the most common reason that window is missed.

There is also a capability dimension worth designing for. If inbound integration is batch where it should be event-driven, the platform behaves like a scheduled system regardless of what it can do: Gartner found that while 95 percent of supply chains must react quickly to change, only 7 percent can execute decisions in real time.

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

Where Locus fits

Locus, the world’s first Decision-Intelligent, Agentic TMS, deploys as the system of execution alongside systems of record, so ERP and WMS retain data ownership and no upstream system has to change to support dispatch. Interfaces are API-first and event-driven, with batch retained for master data and rate tables where batch is correct.

Within DiSCO, the Hub agent manages facility readiness and the dispatch handover, which is the boundary where check two lives, and the Settlement agent reconciles cost back to finance, which is one of the outbound flows in check eight.

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.

Ask any platform, including this one, which of your specific systems have pre-built connectors versus configured integrations, who performs the build, and who maintains it when the other vendor changes their API. The answer to the third question determines your cost profile after go-live rather than during it.

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

The one to do this week

If your project has started and master data is not reconciled, stop building interfaces.

Every one constructed on unmatched identifiers will need revisiting, and the cost of revisiting is higher than the cost of the reconciliation, in every case. It is the only item on this list where deferring is strictly more expensive than doing it now.