Integrating TMS, ERP and telematics with a new dispatch platform

Logistics system integration is the work of making a new dispatch platform talk to the transport management system, the ERP and the telematics provider you already run, without first replacing any of them. The temptation is to bundle the integration into a rewrite. The better approach in the first phase is an adapter per system: a thin service that translates that system's data and quirks into the events the dispatch platform understands. This article explains what each adapter does, how to handle systems with no API, and how to sequence the work so dispatch goes live before the ERP project is finished.

Why integrate before you replace

A dispatch platform is valuable on day one because it sees orders, vehicles and drivers together and assigns work well. It does not need to own the order master, the invoice ledger or the GPS hardware to do that. The TMS already holds contracts and rates. The ERP already posts invoices and pays vendors. The telematics box already reports position and ignition. Replacing any of them stalls the dispatch project behind a migration that has nothing to do with dispatch.

Adapters let the platform go live against real data in weeks, and they give you an honest inventory of each system's data quality before you decide whether to replace it. The logistics industry page describes how we sequence these phases.

The three systems and what the dispatch platform needs from each

TMS integration: orders in, status out

The TMS is usually the system of record for what has to be moved. Dispatch needs a reliable stream of new and changed consignments, and the TMS needs statuses back so customer service and billing keep working. The failure modes are well known: the TMS has an API but it is rate-limited or only returns a day's data at a time; consignment updates overwrite each other; cancellations arrive after the vehicle has left.

The adapter should poll or subscribe, normalise consignments into the platform's own order model, deduplicate by consignment number and version, and emit an event per change. Status writes go back through a queue with retries, because the TMS will be unavailable during the night batch. Store a mapping table of TMS identifiers to platform identifiers; you will need it for every support call.

ERP integration: the money side

The ERP cares about three things from dispatch: what trips cost, what drivers and vendors are owed, and what cash was collected. Each of these is a document the ERP already knows how to post, so the adapter's job is to produce those documents correctly rather than invent a new ledger. Trip costs become expense lines against a cost centre. Settlements become vendor payables. COD deposits become receipts against the shipper's account, which we covered in cash-on-delivery reconciliation automation.

Modern cloud ERPs expose APIs; older ones expect files in a folder, sometimes on a fixed schedule. Either is fine. What matters is that the adapter produces a batch with an identifier, records what was sent, and can be re-run without double-posting. For SAP or Oracle, the customer's existing middleware is often the right path, and the adapter writes to the middleware rather than to the ERP directly. Our API development and integrations work covers this layer.

Telematics API: turning positions into events

Telematics vendors offer either a webhook that pushes position and event data or an API that you poll. Both produce far more data than dispatch needs. The adapter's job is to turn thousands of position points into a small number of meaningful events: vehicle arrived at pickup, vehicle left geofence, vehicle idle beyond threshold, ETA changed by more than a set margin.

Fleet data integration goes wrong when the raw feed is written straight into the dispatch database. Store the raw feed separately, with retention rules, and let the adapter publish only derived events. This keeps the platform fast, keeps the storage bill predictable, and means a change of telematics vendor changes one adapter rather than the platform. If the vendor supports MQTT, an MQTT consumer is usually simpler and more reliable than polling; the Eclipse Paho and Mosquitto projects on GitHub are the reference implementations most teams start from.

Systems with no API

Some of the systems you must integrate have no API at all: a decade-old TMS that only exports CSV, an ERP whose vendor charges for an integration licence, a customer portal that only shows data on screen. There are four options, in order of preference.

• Database view: if the vendor allows read access, a view over the relevant tables is the most reliable feed, and often the fastest to build
• Scheduled file export: most legacy systems can export to a folder on a timer; the adapter watches the folder and processes new files idempotently
• Report scraping: run the system's own report and parse the output; brittle when the report layout changes, so version it and alert on parse failures
• Robotic process automation: drive the screen; last resort, because it breaks on every UI update and cannot run at volume

Whichever route you take, mark the source and freshness of every record so dispatchers know when data is an hour old.

Events, not point-to-point calls

With three or more systems, point-to-point integrations multiply quickly. A small event backbone, whether a managed queue or a Kafka-style log, lets each adapter publish what it knows and lets the platform, the ERP adapter and future analytics subscribe independently. It also gives you replay when an adapter has a bug. This is the same pattern we describe for finance, identity and messaging in integrating a new platform with finance, identity and messaging.

Data quality and identity

The unglamorous part of logistics system integration is deciding which system owns each entity. The TMS owns consignments, the ERP owns customer and vendor masters, and the telematics vendor owns device identity, but the platform must map device to vehicle to driver, and that mapping changes daily. Build one mapping service and make every adapter use it. Most production integration bugs are identity mismatches: a device swapped between trucks, a customer duplicated in the TMS.

A worked example

A last-mile operator asked for a new dispatch platform and an offline-first driver app. Their TMS was a vendor product with a limited API, their ERP was an older on-premise system that imported files, and telematics came from two vendors after an acquisition. Rather than rationalise any of this first, we built four adapters: a polling TMS adapter with a mapping table, a file-based ERP adapter producing settlement and cost batches, and one telematics adapter per vendor publishing a common event schema.

Dispatch went live on the new platform while every legacy system stayed in place. Over the following months, the operations team used the adapters' data-quality reports to decide which systems deserved replacement and which were fine as they were. The build is described in the dispatch platform and field apps case study.

Team and timeline

Integration work for a dispatch platform usually runs alongside the platform build rather than after it. A typical team is one integration engineer per two systems, a backend lead who owns the event schema and mapping service, and a delivery lead who negotiates access with each vendor, which is often the slowest part. Expect the TMS and telematics adapters to take three to four weeks each, and the ERP adapter to depend on the finance team's availability for testing.

As a standalone engagement, API development and integrations starts at $7,000 or ₹4.4L per system. Within a full platform build, it is scoped inside product and platform development, from $42,000 or ₹28L. Where the legacy landscape is unclear, a Sprint Zero at $3,250 or ₹2,00,000 maps every system, its access route and its data quality before the build is priced; see the pricing page for how it is credited.

Before you start: a checklist

• List every system that holds orders, vehicles, drivers, customers or money
• For each, find out whether it has an API, a database, a file export or only a screen
• Get vendor contacts and confirm licensing for integration access
• Decide which system owns each entity and write it down
• Define the event schema the dispatch platform will consume
• Agree who tests ERP postings and when they are available
• Decide retention for raw telematics data
• Plan a replay mechanism for every adapter

Questions clients ask

• Should we replace the TMS as part of this? Not in phase one. Integrate, learn its data quality, then decide.
• Can two telematics vendors coexist? Yes; one adapter per vendor publishing the same event schema.
• What if the ERP vendor refuses API access? File-based import on a schedule is reliable and widely supported.
• How do we handle a vendor change later? Replace the adapter; the platform and other adapters are untouched.
• Is an event backbone overkill for three systems? For three systems with replay needs, a managed queue is small and worth it.

Related reading

Read dispatch and routing engines for what the platform does with the data, building an offline-first driver app for the field side, and the logistics ERP overview for the money flows.

Adapters first, replacements later: the dispatch platform goes live on real data, and every legacy decision is made with evidence.