Every carrier we talk to has a TMS. Most of those TMS platforms are doing the job they were built to do: order management, load tendering via EDI 204, carrier status updates via EDI 214, billing, BOL generation via EDI 211, and the static route planning cycle. The platform team at McLeod or MercuryGate or Trimble TMW didn't fail to build real-time re-optimization — they built something different, which serves a different operational scope.
The question isn't whether your TMS needs to be replaced. It doesn't. The question is how you add a real-time re-sequencing capability to the manifest data that already lives in your TMS, without creating a parallel system that dispatchers have to maintain separately.
That integration design is the hard part. This article is about what the practical integration patterns look like, where they typically break, and how to avoid the failure modes we've seen in production deployments.
What the TMS Knows and What It Doesn't Know in Real Time
A well-configured TMS at manifest lock has a reliable picture of: planned stop list per route, vehicle assignment, planned sequence, estimated time of arrival per stop, and driver assignment. This is the data the re-optimization engine needs as its starting state.
What the TMS typically does not maintain in real time: current loaded capacity per vehicle (versus planned capacity), current driver HOS position (versus planned hours), current GPS position per vehicle, and stop completion status during execution. That live operational data lives in your ELD system (Samsara, Verizon Connect, or a comparable platform), your driver app, and potentially your telematics provider.
The integration architecture for real-time re-optimization has to pull from both sources: TMS for the authoritative planned state, ELD/telematics for the live execution state. Without both, the re-optimizer has incomplete constraints. A sequence computation that doesn't know the driver is 45 minutes into their 11-hour HOS window versus 3 hours in will produce different — and potentially non-compliant — results.
Integration Pattern A: Polling-Based Manifest Sync
The simplest integration pattern is a scheduled polling connection from the re-optimization platform to the TMS's route data export. At a defined interval — typically every 5–15 minutes during the pre-departure window — the re-optimizer pulls the current manifest state from the TMS and maintains a synchronized internal representation.
This works well for operations where the cutoff window is relatively wide (30+ minutes before departure) and where manifest changes are batched rather than continuous. A carrier running a 4 p.m. cutoff with a 5 p.m. departure has a full hour in which the polling sync can keep the re-optimizer current. By the time the dispatcher needs to act on a late exception batch, the re-optimizer has an up-to-date manifest state to work from.
The failure mode with polling is latency. If the polling interval is 10 minutes and a dispatcher makes a manual change in the TMS at T-minus-3-minutes, the re-optimizer's internal state may be stale when it runs the re-sequence computation. In systems with tight departure windows, polling-based sync requires either a very short polling interval (sub-5-minute) or a mechanism to trigger a forced refresh when the exception batch arrives.
MercuryGate and McLeod both expose route data via API endpoints suitable for polling-based integration — the specifics vary by version and configuration. If your TMS IT team has locked down external API access, the alternative is a flat-file export pushed to a shared SFTP location at a defined interval, which most TMS platforms support and which avoids direct API connection requirements.
Integration Pattern B: Event-Driven Webhook Push
A cleaner architecture for tight departure windows is an event-driven integration where the TMS pushes a notification to the re-optimization platform whenever a manifest change event occurs — a stop addition, removal, address modification, or vehicle reassignment. The re-optimizer receives the event and updates its internal state immediately, without waiting for the next poll cycle.
This requires the TMS to support outbound webhooks or event notifications — a capability that varies significantly by platform and version. Newer TMS deployments and cloud-hosted platforms typically have this capability. Older on-premise installations of platforms like McLeod PowerBroker or Trimble TMW may require a middleware layer to generate events from database change detection.
The advantage of event-driven integration is that the re-optimizer's state is always current. When the late exception batch arrives, the re-sequence computation starts from an accurate representation of the manifest — no stale data, no forced refresh delay. For depots with departure windows under 30 minutes post-cutoff, event-driven is the architecture that actually works under time pressure.
Parcelarc's integration architecture supports both polling and event-driven patterns through its constraint API. The integrations page covers the connector configuration for common TMS platforms including the webhook endpoint specification for event-driven sync.
The ELD Data Layer: What It Adds and Where It Complicates
Adding ELD data to the integration enriches the re-optimization with live HOS position per driver and live GPS position per vehicle. Both are valuable for constraint-accurate re-sequencing. They also add integration complexity.
ELD platforms — Samsara, Verizon Connect, and comparable providers — have well-documented APIs for pulling current HOS data and GPS position. The challenge is authorization: ELD data is FMCSA-adjacent (governed by 49 CFR 395 compliance requirements), and carriers have legitimate IT security reasons for controlling who can read ELD data from their fleet systems. Integrating the re-optimizer with the ELD layer typically requires IT review and a formal data sharing agreement defining what fields can be accessed, how long data can be retained, and what the security standards are for the receiving system.
For carriers who haven't gone through that authorization process, the fallback is driver-reported HOS position via the driver app — less precise than pulling directly from the ELD, but operationally sufficient for most re-sequencing decisions. The re-optimizer uses reported HOS remaining as a soft constraint, flagging routes where the computed sequence would push the driver within 1 hour of their remaining HOS window rather than hard-blocking the sequence entirely.
We're not saying ELD integration is optional for best results — it produces more accurate constraint handling. We're saying it's optional for initial deployment, and carriers can go live with TMS-only integration first, then add ELD data as the IT authorization process completes.
Handling the Writeback: How Re-Sequenced Routes Get Back into the TMS
A common integration question: after the re-optimizer computes a revised sequence, does it write the new sequence back into the TMS? Or does the TMS remain on the original planned sequence?
There are operational arguments for both approaches. Writing back the revised sequence keeps the TMS authoritative for billing, customer notification, and post-route reporting — the TMS knows what actually happened, not just what was planned. Not writing back preserves the original plan in the TMS for comparison and avoids the risk of the writeback triggering downstream TMS automations (customer notifications, EDI 214 status updates) that are based on the new sequence rather than the original commitment.
In practice, most carriers we work with start with a read-only integration — the re-optimizer reads TMS data and pushes updates to the driver app, but doesn't write back to the TMS. Dispatcher workstations show both the TMS planned sequence and the Parcelarc re-optimized sequence in a side-by-side delta view. After the route completes, stop completion data from the driver app is reconciled against the TMS record for billing and reporting purposes.
As carriers gain confidence in the re-sequencing output quality and data accuracy, moving to a writeback architecture — where the revised sequence becomes the authoritative TMS record after dispatcher approval — reduces the reconciliation step. The re-optimization pipeline overview covers how the Parcelarc dispatch console is designed to support both integration modes with the same core connector architecture.
Where Integrations Actually Break in Production
Most integration failures we've seen in production fall into three categories. First: authentication expiry. A TMS API token that was valid at integration setup expires 90 days later, the polling sync silently fails, and dispatchers use stale re-sequenced output for two days before anyone realizes the data is from 3 days ago. The fix is automated token refresh and an active monitoring alert when the sync hasn't received a fresh manifest within the expected interval.
Second: schema drift. TMS vendors push minor updates that change field names, add required parameters, or modify how stop status codes are reported. A minor TMS version update breaks the integration connector until the field mapping is updated. The mitigation is running the integration in strict validation mode so mapping errors surface as explicit alerts rather than silent data misreads.
Third: capacity field mismatch. The TMS's capacity model uses dimensional weight for vehicle fill calculation; the re-optimizer uses physical weight or stop count. Routes that look under-capacity to the re-optimizer are actually at vehicle limit by the TMS's dimensional-weight accounting. The re-optimizer proposes an insertion that dispatchers can't execute. The fix is aligning the capacity model before go-live — a configuration step, not an integration fix, but one that's regularly overlooked until the first live exception.
Each of these is solvable and predictable. The carriers who avoid them do a pre-integration configuration audit against their TMS's specific data model before connecting live traffic. For carriers evaluating Parcelarc, that audit is part of the onboarding process — the carrier onboarding overview covers what that configuration step involves and how long it typically takes for a single-depot initial deployment.