ELD and Hours of Service Integration

Why ELD data belongs outside the ELD

Since the federal ELD rule took full effect, nearly every interstate carrier records duty status electronically. The trouble is that the data usually stays inside the ELD vendor’s portal. Dispatchers plan loads in a TMS or a spreadsheet, check hours by calling the driver or opening a second screen, and learn about a violation after it happens. Tepia builds integrations that move hours of service data into the places where load decisions are actually made.

The rules behind those decisions are specific. A property carrying driver may drive up to 11 hours within a 14 hour on duty window after 10 hours off, needs a 30 minute break after 8 hours of cumulative driving, and is limited to 60 or 70 on duty hours across 7 or 8 days unless a 34 hour restart resets the cycle. Sleeper berth splits, the short haul exception, adverse driving conditions, personal conveyance and yard moves all change the math. An integration that only shows a single hours remaining number misses most of that.

Tepia’s job is to read the clocks your ELD already computes, combine them with load and appointment data, and answer the dispatcher’s real question: can this driver legally make this delivery window, and if not, who can.

What an ELD and HOS integration includes

Tepia scopes the integration around the decisions your planners and safety team make every day. A typical build covers these capabilities:

Detention shows why this data matters beyond compliance. When the ELD shows a driver sat on duty at a receiver for four hours, Tepia matches that time to the appointment and produces the record your billing team needs to claim detention from the shipper, instead of relying on the driver’s memory a week later.

Working with Samsara, Motive, Geotab and other ELD providers

Most large ELD providers publish APIs that expose drivers, duty status changes, clocks and violations. Tepia integrates through those REST APIs and webhooks, and the pattern is similar each time: authorize against the carrier’s account, subscribe to duty status events, receive or poll the computed clocks, and store a normalized copy for dispatch and reporting. For deeper work on the vehicle side, see our telematics integration with Samsara, Geotab and Motive.

A few practical points shape the design:

• Clocks come from the ELD. Tepia displays the provider’s computed hours rather than recalculating them, so your dispatch board never disagrees with what an inspector sees on the driver’s device.
• Freshness matters. Some feeds update within seconds and others less often, so the board shows when each driver’s data was last refreshed.
• Owner operators bring their own devices. Leased drivers may run an ELD you do not control, and Tepia builds a consent and connection flow for those accounts.
• Records stay in the ELD. FMCSA expects carriers to keep records of duty status and supporting documents for six months, and the registered device remains the source; Tepia’s copy is for operations, not a replacement.

How Tepia approaches ELD and hours of service integration

Tepia applies its six phase process here with a US based project manager, and engineering leadership reviews your ELD provider’s API early in Discovery so surprises surface before design.

1. Discovery: a full shift with dispatch, an inventory of every ELD account and device type in the fleet, and a review of how loads are tendered. Deliverables are an Investigation Summary, an Interview Summary and User Stories such as a planner checking whether a driver can make a 6 a.m. appointment after a restart.
2. Design: a design questionnaire, moodboards, a style guide and wireframes for the driver card, the feasibility check and alert rules, reviewed with your safety manager.
3. Development and Testing: an Alpha against one terminal’s drivers and a Beta across the fleet, with test plans that replay real duty status histories, including split sleeper and short haul days, and compare results to the ELD.
4. Training: remote and in person sessions for planners, safety staff and drivers, covering what each alert means and what to do about it.
5. Launch: backfill of recent duty status history, a parallel run with your current process, then a cutover terminal by terminal with support reps watching the first week of alerts.
6. Support: issue resolution, bug tracking and feature requests, plus updates when a provider changes its API or FMCSA amends the rules.

An integration into an existing dispatch system often moves faster than the typical ranges of 1 to 3 months of Discovery, 2 to 6 months of development and QA and a month to launch. More on how Tepia works.

Integrate, build a dispatch tool, or stay in the ELD portal

Not every carrier needs this. If you run ten trucks on one ELD with a dispatcher who knows every driver, the provider’s portal and alerts may be enough, and Tepia will tell you so. Integration pays off when:

• You run more than one ELD provider because of acquisitions or leased owner operators.
• Dispatchers plan in a TMS or custom board that cannot see hours.
• Violations or unassigned driving events are showing up in audits or CSA scores.
• You want hours, detention time and appointments in one report for customers and drivers.
• Driver pay depends on on duty time that today is reconstructed by hand each week.

When the dispatch tool itself is the bottleneck, Tepia can build that too; see dispatch software for trucking and freight and trucking company app development. Contact Tepia to review your ELD setup.

Frequently asked questions