The phrase "system integration" triggers anxiety in most regional courier operations for good reason. It usually means months of IT work, consultants who charge more than the software itself, and the discovery that the systems you thought would talk to each other don't actually communicate in compatible formats. Then you go live on a Monday and spend two weeks debugging.
The good news is that connecting a TMS to routing sequencing software is considerably more tractable than it was five years ago — not because the underlying data problems went away, but because the architecture pattern that works has become well-established. This guide outlines the integration approach that gets regional carriers connected without an IT project.
Understanding What Needs to Cross the Boundary
Before thinking about integration method, be precise about what data actually needs to flow between systems. For a routing sequencing layer connected to a TMS, there are three essential data flows:
- Outbound from TMS: planned stops for the day — addresses, time windows, package counts/weights, any special instructions. This is the route manifest before sequencing.
- Inbound to TMS: re-sequenced manifest — same stops, re-ordered, with estimated arrival times and (if available) availability confidence scores per stop.
- Delivery outcomes back to routing system: actual delivery outcome per stop (success, failed attempt, reason code) — this is the feedback loop that improves signal quality over time.
Everything else — driver tracking, proof of delivery capture, customer notifications — stays in your existing TMS and driver app. A sequencing layer doesn't need to see it. Keeping the integration scope narrow is how you avoid the months-long IT project.
The Three Integration Patterns
Pattern 1: File Exchange (CSV/JSON drop)
The simplest integration is a scheduled file export from your TMS and a scheduled import of the re-sequenced manifest. Your TMS exports tomorrow's planned stops as a CSV or JSON file at a scheduled time (typically late afternoon or evening, after route building). The sequencing system picks up the file, processes it, and writes back a re-sequenced version that your TMS imports before driver dispatch in the morning.
This pattern requires no API work and no real-time connection. It works with virtually any TMS that supports scheduled exports. The limitation is the batch processing window — you can't re-sequence mid-route if conditions change, and the turnaround time depends on how long the sequencing process takes.
For carriers running 10–50 routes with a planning window that ends the evening before, file exchange is often entirely sufficient. It's not glamorous, but it works and the operational impact doesn't depend on real-time connectivity.
Pattern 2: REST API Integration
API integration enables real-time or near-real-time exchange. Your TMS calls the routing system's API endpoint with a stop manifest payload; the routing system returns a re-sequenced manifest in the response (typically within 60–90 seconds for a route of 30–50 stops). The TMS can trigger this call as part of its normal route-finalization workflow.
A typical API payload structure looks like this:
POST /v1/sequence
{
"route_id": "RT-20251204-07",
"vehicle_id": "VH-0038",
"stops": [
{
"stop_id": "S001",
"address": "247 Maple Ave, Columbus OH 43209",
"time_window_start": "09:00",
"time_window_end": "17:00",
"service_time_minutes": 3,
"weight_kg": 2.4
},
{
"stop_id": "S002",
"address": "8 Prospect Rd, Gahanna OH 43230",
"time_window_start": null,
"time_window_end": null,
"service_time_minutes": 2,
"weight_kg": 0.8
}
]
}The response returns the same stops in re-sequenced order, with estimated arrival times and availability scores appended. Your TMS ingests this response and updates the driver manifest accordingly.
The integration work for this pattern is typically 1–3 days for a developer familiar with REST APIs. The main variable is how your TMS handles incoming sequence updates — some TMS platforms accept API callbacks natively, others require a thin middleware adapter that maps the sequencing system's response format to the TMS's expected import format.
Pattern 3: Webhook-Based Bidirectional Integration
For carriers that want delivery outcomes to flow back to the routing system in real time — to improve signal quality continuously and to enable mid-route re-sequencing for remaining stops — webhook integration closes the loop. When a driver records a delivery outcome (successful scan, failed attempt, or attempt-with-code), the TMS fires a webhook event to the routing system. The routing system updates its model and, if configured, can push a revised sequence for the remaining stops back to the driver app.
This pattern is the most complex and requires that both your TMS and your driver app support webhooks or event-driven APIs. It's worth building for carriers running high-volume residential routes where mid-day re-sequencing based on early-stop outcomes could recover additional first-attempt successes. For most regional carriers at 15–80 daily routes, the file exchange or simple API pattern delivers the primary value without the real-time complexity.
What to Check Before Starting Integration Work
Before any development begins, answer these questions about your TMS:
- Does your TMS support scheduled CSV/JSON export of planned routes? If yes, file exchange is immediately viable.
- Does your TMS have an outbound API for route data? If yes, what authentication model (API key, OAuth)?
- What data format does your TMS expect for reimporting a re-sequenced manifest? (This is often the underdocumented part — every TMS has idiosyncratic import format requirements.)
- Does your driver app accept sequence updates after dispatch? Some driver apps lock the manifest at driver sign-on; real-time re-sequencing requires an app that supports mid-route updates.
The Middleware Adapter Approach
If your TMS and the routing system don't have compatible formats out of the box — which is common; TMS data schemas vary widely — the most maintainable solution is a thin middleware adapter: a small service that translates between your TMS's export format and the routing system's API format, and translates the routing system's response back to your TMS's import format.
This adapter is typically 200–400 lines of code, handles format mapping and error handling, and can run as a scheduled job (for file exchange patterns) or as a lightweight API service (for real-time patterns). Once it's built, it's low-maintenance — it only needs updates when either system's format changes, which for mature platforms is infrequent.
The adapter approach also keeps the integration decoupled — if you switch TMS vendors in two years, you update the adapter's TMS side without touching the routing integration. This is preferable to deep bi-directional integration that entangles both systems.
Realistic Timeline and Effort
For a regional carrier with a developer or a contract developer available, a file-exchange integration is typically operational in 3–5 business days. A REST API integration with a well-documented routing system API adds another 1–3 days for adapter development and testing. Webhook-based bidirectional integration adds another week of development and testing, assuming both TMS and driver app are cooperative.
The timeline risk is almost never in the routing system's API — modern routing SaaS APIs are well-documented and consistent. The timeline risk is in your TMS's export format documentation, which is often incomplete, and in how your TMS handles re-import of modified manifests, which tends to be the least-tested pathway. Build your testing plan around the TMS import step, not the routing API step.