Everything that goes wrong in a small carrier’s integration project goes wrong because somebody worked around the documented interface.
Key takeaways
You extend a TruckMate or McLeod system at the seams the vendor documents — the EDI layer, the published API, and the integration catalogue — and you do not go near the database. Both vendors have built those seams deliberately, and everything that goes wrong in a small carrier’s integration project goes wrong because somebody worked around them.
That is the whole answer, and it is unglamorous. The interesting question is which of the four extension patterns your problem actually is, because the cost and the risk differ by an order of magnitude between them.
McLeod. The EDI capability is documented as native rather than bolted on: McLeod describes its EDI engine as a fully integrated part of the software, built from the ground up by its development team, and a user-configurable engine rather than a hard-coded custom solution. On formats and transport, it documents support for multiple formats beyond traditional ANSI X12 including XML and JSON, with FTP, SFTP, AS2, external API and its own API endpoints. On the integration side, McLeod documents over 260 off-the-shelf, fully tested integrations backed by more than 140 certified partners, a RESTful API framework giving secure two-way access to TMS data, and an integration dashboard showing which licensed integrations are active.
Trimble TruckMate. Trimble positions TruckMate as transportation management for LTL carriers, covering order entry through to settlement, and spanning LTL to truckload, intermodal to multimodal, and points integrators at a transportation developer portal for building against it.
The point of quoting the vendors rather than summarising them is that these are the documents your integrator will be held to. If a capability is not in them, it is a project, not a configuration.
Anything that is not one of these four is usually a request to replace the system, wearing an integration’s clothes.
Write to the system only through the documented interface. Geotab’s developer documentation puts the reason bluntly in a line that applies to any operational platform: API writes change the selected database immediately, so develop with test entities, protect tools from selecting the wrong database, and reconcile uncertain outcomes before retrying a write. It also warns that the API is not a single flat data export — entities have relationships, searches have type-specific behaviour, and high-volume records require bounded queries or feeds.
Direct database writes break exactly this. They bypass the validation the vendor wrote, they are invisible to the audit trail, and they turn every upgrade into a risk. McLeod makes the same point positively when it describes its API framework as maintaining the integrity of your business rules and validations. Those validations are the product.
Even read-only integrations have a shape, and Geotab’s SDK names it usefully: use a bounded query for current state, and a checkpointed feed to maintain a stream of supported changes, with a separate connector for large historical analysis. The same three shapes apply to a TMS.
The failure mode when this is ignored is predictable. Someone builds a report that re-queries the whole order table every fifteen minutes, it is fine at launch, and as volume grows it starts timing out during the morning dispatch window — which is the one hour of the day when nobody can afford it.
Worked example: three weeks, one integration, no replacement
A carrier running McLeod across 40 power units had a specific complaint: the customer service desk answered the same question forty times a day — where is my load — and each answer meant looking in two systems.
The scoping conversation started with a request to replace the TMS. It ended with a two-part integration. First, a read-only feed of load status and location out of the TMS into a small customer view, refreshed on change rather than on a timer. Second, an outbound status message to the three customers who had asked for one, mapped to the codes each had specified.
What made it work was scope discipline. Rating, billing, driver pay and dispatch logic were declared out of scope on day one and stayed out. Nothing was written back into the TMS at all in phase one, so the worst possible failure was a stale customer view rather than a corrupted order. The desk stopped answering forty calls a day inside a month, and the TMS was never touched.
Rarely, and almost never for the reason first given. A replacement costs the migration, the retraining, the re-onboarding of every EDI trading partner, and a period of reduced service. If the complaint is a missing report, a manual re-key or a customer view, it is an integration. If the complaint is that the system cannot represent your business at all — a mode you do not run, a settlement model it cannot express — that is a replacement conversation.
Check the catalogue first. McLeod documents over 260 off-the-shelf, fully tested integrations and an integration dashboard for seeing which are active. A supported integration you configure beats an unsupported one you maintain.
A named person in operations, not only the vendor. Integrations fail quietly — a feed stops, and for two days everyone believes the data is current. Someone has to be responsible for noticing.
No, and it should not. These patterns move data, extract it, and draft text. Accepting freight, dispatching a driver, releasing an invoice and judging whether a driver is fit to be sent are decisions a person makes and signs. See dispatch software for trucking companies for where that line sits on the dispatch desk.
We will scope the integration against the vendor documentation and tell you honestly if it is a replacement.
