There are two ways data leaves an electronic logging device, and only one of them is meant for your dispatch board.
Key takeaways
Through the ELD vendor’s application programming interface — not through the roadside data-transfer channel. Those are two different outputs built for two different readers. The transfer mechanism exists so an inspector can take a copy of a record of duty status at the roadside; the API exists so your own systems can read hours and position continuously. Confusing them is the single most common reason an integration project stalls.
Once the feed is in, the useful thing to put in front of a dispatcher is not a log. It is remaining available hours per driver, refreshed often enough to plan the afternoon.
An ELD is a device or technology that automatically records a driver’s driving time and facilitates the recording of the driver’s record of duty status, and that is certified by an accredited certification body. Certification is against a national standard, and it moved recently: Transport Canada records that the CCMTA Technical Standard for ELDs version 1.3 was made public on September 29, 2025, replacing version 1.2 previously posted on October 27, 2020, and that Transport Canada leads the process for implementation and coming into force, recognising that ELD providers and certification bodies need a transition period. Transport Canada also publishes a registry of accredited certification bodies and a list of certified devices. If you are choosing a device this year, that list is the starting point rather than a vendor’s claim.
The roadside path is prescribed as documentation the truck carries: the carrier must ensure that each commercial vehicle carries an ELD information packet containing a user’s manual, an instruction sheet describing the data transfer mechanisms supported by the ELD and the steps required to generate and transfer hours-of-service data to an inspector, a malfunction instruction sheet, and enough blank records of duty status for at least 15 days. Nothing in that describes an integration. It describes what a driver hands over at a scale.
Vendor platforms expose the underlying records as objects you can poll or subscribe to. Geotab documents a LogRecord object holding the GPS position and date-time recorded by a device — the raw position trace. Samsara documents an endpoint to get all driver hours-of-service daily logs — the duty-status side. Those are capability statements from the vendors’ own documentation, not performance claims, and they are the right shape for the two things dispatch needs: where the truck is, and how much time the driver has left.
Design the integration one-directional. The regulations prohibit a carrier from requesting, requiring or allowing anyone to enter inaccurate information in a record of duty status or falsify, alter, delete or deface the records or supporting documents, and from tampering with an ELD so that it does not accurately record and retain required data. Where a correction is genuinely needed the regulated route is that the carrier verifies the certified records against the supporting documents and requires the necessary changes, and the driver accepts or rejects the changes, makes them and recertifies. A TMS that pushes edits into logs is not an efficiency; it is a finding.
Three feeds, not one
Keep them separate in your head and in the architecture. Inbound from the ELD: position, duty status, remaining hours, malfunction and diagnostic codes. Internal: the dispatch board, load assignments, planned arrival times. Outbound to customers: shipment status, which in most shipper relationships travels as an EDI 214 — a message that communicates a shipment’s current progress, including its current location, current status and tracking number. Wiring the ELD directly to a customer feed skips the layer where a human decides what the customer is told.
Two regulatory requirements shape how clean the feed will be. First, the motor carrier must create and maintain a system of accounts for ELDs that complies with the Technical Standard, allowing each driver to record their record of duty status in a distinct and personal account, and providing a distinct account for the driving time of an unidentified driver. If your fleet shares logins or leaves movement stranded in the unidentified-driver bucket, no integration will fix the resulting picture. Second, no motor carrier shall request, require or allow a driver to use, and no driver shall use, more than one ELD at the same time for the same period.
Malfunctions need a path too. Where an ELD malfunctions the carrier keeps a defined record and must retain that information for each affected ELD for a period of 6 months from the day the ELD is replaced or repaired. That is a natural thing for the integration to capture automatically, and a common gap when it is handled by email.
A 22-truck Ontario carrier wants remaining hours on the dispatch board, refreshed every 15 minutes across a 14-hour dispatch day. Polling per driver gives 14 × 4 = 56 refreshes a day per driver, and 56 × 22 = 1,232 calls a day. Using a fleet-wide endpoint that returns all drivers in one response gives 56 calls a day — the same freshness for 1,232 ÷ 56 = one twenty-second of the request volume. That is the difference between an integration that a vendor plan comfortably supports and one that spends its first month being rate-limited.
The dispatcher’s view is then a simple derivation. A driver on cycle 1 must not drive after accumulating 70 hours of on-duty time in any period of 7 days. A driver showing 61 hours accumulated has 70 − 61 = 9 hours before the cycle ceiling, and that is the number that decides whether the Thursday afternoon load is theirs or somebody else’s. On cycle 2 the limits are 120 hours in any period of 14 days, and 70 hours without having taken at least 24 consecutive hours off duty, so a driver on 66 hours since their last full day off has 4 hours before that second constraint bites — which is a different and often earlier wall than the 14-day one.
The integration itself is plumbing. The value sits on top of it: turning a raw event stream into a plain-language dispatch view, matching a position trace against the planned stop sequence so a slipping arrival is visible before the customer notices, reconciling certified records against fuel receipts and gate times so the carrier’s verification duty is genuinely discharged, and drafting the customer-facing status note that a dispatcher approves and sends.
It does not dispatch. Whether a driver takes a load, whether a log is accurate, and whether a truck is fit to move are decisions a person makes. If you want the wider picture of what to automate first, this hub’s overview of AI in trucking dispatch covers the ground, and the note on dispatch software for trucking companies covers the platform side.
No. Corrections run through the regulated route: the carrier requires the necessary changes after verifying against supporting documents and the driver accepts or rejects them and recertifies. Direct editing is caught by the prohibition on entering inaccurate information or altering, deleting or defacing records.
It is the wrong tool. The transfer mechanism is documented for the driver in the ELD information packet, whose instruction sheet describes the supported data transfer mechanisms and the steps to transfer data to an inspector. Dispatch needs a continuous feed, which is what the vendor API is for.
Transport Canada has said it leads the process for implementation and coming into force of version 1.3, recognising that ELD providers and certification bodies need a period of transition, and that its pages will be updated with information on testing, certification and roadside enforcement. Check the list of certified devices rather than assuming either way.
Not necessarily, and it is usually better that you do not send it raw. Customer status normally travels as its own message — an EDI 214, which carries current location, current status and tracking number — assembled from the dispatch record. That keeps a human decision between a telematics event and a customer promise.
A 30-minute call is enough to tell you whether AI pays for itself in your back office.
