Modern motor carriers operate complex technology stacks that must reconcile real-time telematics data from multiple ELD providers with enterprise Transportation Management Systems (TMS). Whether running Truckmate, McLeod, or TMW, the ability to ingest, normalize, and act on Geotab, Samsara, and Motive duty-status, location, and exception events directly impacts dispatch efficiency, HOS compliance, driver settlement accuracy, fuel surcharge validation, and detention billing.
Strong Tower Consulting has spent more than 18 years designing and implementing these integration architectures for asset-based carriers. This guide presents the reference architecture we deploy in production environments, including REST webhook ingestion patterns, OAuth2 token rotation strategies, real-time duty-status mapping to TMS pre-dispatch checks, and exception alerting tied to EDI 204 tender acceptance and 214 status reporting.
The Business Case for Unified Telematics Integration
Carriers that maintain separate silos for each ELD provider lose visibility into true driver availability. A driver appearing available in the TMS may actually be approaching their 11-hour driving limit according to Samsara, or may have an unresolved Motive exception that blocks load assignment. Integrating these systems at the architectural level enables pre-dispatch HOS validation, automated exception routing, and accurate driver settlement calculations that include detention, fuel surcharges, and accessorials.
Reference Architecture Overview
The recommended pattern is an event-driven middleware service (typically hosted in Azure or AWS) that acts as a normalization and orchestration layer between the ELD providers and the carrier's core TMS and data warehouse. This layer is deliberately independent of any specific software product, preserving the carrier's ability to change TMS platforms or add new ELD vendors without rewriting core business logic.
| Provider | Authentication | Primary Event Feed | Duty Status Granularity | Webhook Support | Typical Token Lifetime |
|---|---|---|---|---|---|
| Geotab | API Key + Session | StatusData + LogData | High (1-minute polling) | Limited (requires polling) | Session-based |
| Samsara | OAuth2 | Webhooks + REST | Real-time (seconds) | Native & robust | 60 minutes |
| Motive (formerly KeepTruckin) | OAuth2 | Webhooks + REST | Real-time with rich metadata | Native | 60 minutes |
Core Integration Components
1. Secure Credential and Token Management
Each provider uses OAuth2 with different token lifetimes. Samsara and Motive tokens expire after approximately 60 minutes. The integration service must implement a secure token vault (encrypted at rest) and a background rotation job that refreshes tokens 5 minutes before expiry. Geotab session management is handled through a separate credential store that renews daily. All credentials are stored outside the TMS database to maintain separation of concerns and support audit requirements under FMCSA rules.
2. Webhook Ingestion and Retry Architecture
Samsara and Motive deliver real-time events via HTTPS webhooks. The ingestion service exposes a single normalized endpoint that validates signatures, stores raw payloads in an immutable audit log, and places events onto a prioritized queue. Retry logic follows exponential backoff with dead-letter queues for persistent failures. Geotab data is retrieved through scheduled micro-batch polling (every 90 seconds for critical duty status changes) to simulate near-real-time behavior.
3. Duty Status Normalization and HOS Engine
Incoming events are mapped to a canonical duty-status model that aligns with both FMCSA 395.24 requirements and the carrier's specific TMS business rules. The HOS engine evaluates each status change against the driver's current 14/11/7/8-hour windows, taking into account prior duty status history stored in a SQL Server or PostgreSQL time-series table. Results are written to a staging schema that the TMS can query via stored procedures before allowing dispatch actions.
4. TMS Pre-Dispatch Validation Workflow
Before a load is assigned in Truckmate, McLeod, or TMW, the dispatch application calls a lightweight REST endpoint or SQL function exposed by the integration layer. The service returns a compliance score that includes:
- Remaining drive and on-duty time
- Active exceptions (Motive harsh events, Samsara sensor faults)
- Detention risk based on current location and historical dwell time
- Fuel surcharge eligibility tied to route and driver
If the driver fails the pre-check, the load is held and an alert is routed to the fleet manager via Microsoft Teams or email with a direct link to the exception details.
5. Driver Settlement and Billing Integration
Normalized telematics data is joined with EDI 210 invoice records and internal settlement tables to automate calculation of detention, layover, and fuel surcharge payments. The architecture maintains referential integrity between ELD event IDs, TMS load numbers, and settlement line items, significantly reducing disputes during driver pay processing.
Independent by Design
Implementation Considerations for Enterprise Carriers
Large fleets must consider data volume (some Samsara installations generate over 1.2 million events per day), regulatory audit retention (6 months minimum for ELD records), and multi-tenant security when drivers are leased or owner-operators use their own ELDs. The reference architecture uses separate ingestion pipelines per provider with strict tenant isolation at the database level.
EDI 214 status updates can be enriched with verified location and duty status data before transmission to shippers, improving visibility and reducing carrier liability. Similarly, EDI 204 tender acceptance logic can incorporate real-time HOS checks to prevent downstream compliance violations.
Measuring Success
Carriers that implement this architecture typically see a 35-50% reduction in HOS violations, 18-25% faster dispatch decision velocity, and measurable improvement in driver settlement accuracy. Fuel surcharge capture rates improve when location data is automatically validated against route and accessorial rules.
Next Steps
Every carrier's technology stack, mix of ELD providers, and TMS configuration is unique. Strong Tower Consulting begins every engagement with a technical assessment that maps current data flows, identifies integration gaps, and produces a prioritized roadmap.
Schedule a carrier telematics architecture assessment or contact us at 763-244-1373 to discuss your specific requirements.