Today, operations run on two truths. Telematics shows where the truck is, how fast it's going, whether the driver stopped to rest. The TMS shows the load, the customer, the freight and the deadline. Between the two screens sits a person with a keyboard, copying license plate numbers, arrival times and driver hours from one window to the other. It's slow, it's expensive and, worse, it's wrong a good part of the time.
This guide explains how to connect your tracking platform — SASCAR, Autotrac, Omnilink and the like — directly to the TMS, so that position, driver hours and events arrive on their own. No retyping, no spreadsheet in the middle. This is written by someone who does it in practice: what can be automated, where integrations tend to break, and what the first concrete step is.
The real problem: telematics on one screen, TMS on another
The symptom is always the same. An analyst opens the SASCAR or Autotrac portal, looks at the map, notes the vehicle's arrival at the dock and types that time into the TMS to close out the trip. In the afternoon, they open it again to close out the driver's hours — driving time, stops, meals — and transcribe it onto the timesheet. At the end of the month, someone cross-checks all of it by hand for billing and for eSocial.
Every transcription is a chance for error. A swapped time becomes an irregular workday on paper. A mistyped plate becomes an orphan trip. And the invisible cost is time: two or three hours a day of expensive staff doing copy-and-paste work. The information already exists — it just doesn't cross from one system to the other.
How the integration works, in simple terms
Serious telematics platforms expose an API: an address where your TMS can fetch the data programmatically, without anyone watching the screen. SASCAR, Autotrac, Omnilink, Onixsat and Cobli offer this. The integration work is building the bridge between that API and your TMS — whether it's Rodopar, Sankhya, TOTVS or an in-house system.
In practice, the bridge does three things:
- Reads position and events from telematics at short intervals (every few minutes, or via a notification when something happens).
- Translates the vocabulary of each side — the plate, the driver and the trip must be the same on both the telematics and the TMS.
- Writes to the TMS through the right door, updating the trip, the driver hours or the event without anyone typing.
It's the opposite of a robot that manipulates the screen pretending to be a person. It's system talking to system, through the door each one already offers.
What can truly be automated
It's not all or nothing. You can start with one point and expand. What typically flows from telematics into the TMS:
- Position and route: latitude, longitude and speed updated in the TMS, without opening the tracker's portal. The analyst sees everything on a single screen.
- Arrival and departure (geofences): when the vehicle enters or leaves a customer, a DC or a toll plaza, the event fires and closes out the trip leg automatically. No more times logged by eye.
- Driver hours: start of the workday, driving, stops, meals and rest captured by telematics and written into the TMS — a clean basis for hours-of-service control and eSocial.
- Events and alerts: speeding, route deviation, unplanned stops, geofence violations. They reach the TMS to become an action item, instead of getting stuck in email.
- Odometer and hour meter: mileage for preventive maintenance and cost allocation, without anyone jotting it down on a spreadsheet.
With that data inside the TMS, the next step comes naturally: push it all into a Power BI dashboard and finally have SLA, idle-time and hours-of-service compliance metrics that update on their own.
The common mistakes (and how to avoid them)
Telematics integration looks simple until the second month. The pitfalls we see most often:
- Not matching the key between systems. If the plate, the driver ID or the trip code don't match between telematics and TMS, the integration writes to the wrong records. The first job is to align that master data — before any line of code.
- Confusing time zones. APIs usually return time in UTC. Writing it without converting to Brasília time creates a workday that's three hours too long or too short. It's a classic, silent error.
- Hitting the API every second. Every platform has a request limit. A poorly calibrated integration gets blocked and stops working without warning. The bridge must respect each vendor's pace.
- Not handling failure. The internet goes down, the telematics API is offline for minutes. If the bridge doesn't reprocess what it missed, gaps open up in the trip. A good integration remembers what it has already read and resumes where it left off.
- Geofence too wide. A large-radius fence fires arrival 500 meters from the customer. The time becomes imprecise and the SLA disputable. It's worth calibrating fence by fence.
And the operation? Does it need to stop to integrate?
No. The integration reads and writes in parallel with the daily routine — no one needs to pull the truck off the road or suspend billing. The telematics portal keeps working exactly as before; the bridge simply starts copying what matters into the TMS.
The healthy path is in stages. You bring the integration up reading the data without writing, compare it with what the team types by hand for a few days, and only then turn on automatic writing. When confidence arrives, the manual work switches off on its own — because it no longer makes a difference. The technology disappears so your business can shine.
How to get started
Before writing any integration, three questions solve 80% of the project:
- Which telematics platform, and do you have API access? SASCAR, Autotrac and Omnilink grant API credentials under contract. It's worth confirming with the vendor that this access is enabled.
- Which TMS, and how does it receive data? Rodopar, Sankhya and TOTVS each have their own intake methods — API, database or import. That defines the writing side of the bridge.
- Which pain hurts most today? Start with what costs the most: at most carriers it's hours-of-service control and the automatic closing of trips via geofence.
With that in hand, a small pilot — one fleet, one customer, one type of event — proves the value in weeks, not months. That's exactly what we deliver in the free assessment: we map the telematics, the TMS and the shortest path between the two.
Frequently asked questions
Can SASCAR (or Autotrac) be integrated with Rodopar?
Yes. Both SASCAR and Autotrac expose an API, and Rodopar has intake points to receive position, events and driver hours. The bridge fetches the data from telematics, matches plate and trip against Rodopar's master data and writes it in without anyone typing. It's one of the most common scenarios we integrate.
How long does it take to integrate telematics into the TMS?
A focused pilot — one fleet, one type of event, such as arrival by geofence — usually gets up and running in a few weeks. The full integration, with driver hours, events and dashboard, depends on the number of sources and the state of the master data, but we work in stages so the operation sees value from the first month.
Do I need to stop the operation to do the integration?
No. The bridge runs in parallel with the daily routine and the telematics portal keeps working normally. We first bring it up in read-only mode, compare it with the manual work for a few days, and only then turn on automatic writing. No truck leaves the road and billing doesn't stop.
Which data syncs between the tracker and the TMS?
Position and speed, geofence entries and exits (arrival at and departure from customers and DCs), driver hours (driving, stops, meals, rest), alerts such as speeding and route deviation, plus odometer and hour meter. You choose where to start and expand as confidence grows.
Does the integration work for hours-of-service control and eSocial?
Yes, and it's usually the biggest saving. Telematics already records the start of the workday, driving, stops and rest. Bringing that to HR in a structured way eliminates manual transcription and gives a clean basis for hours-of-service control and eSocial, with far less risk of irregular workdays caused by typing errors.
Why not use a robot that copies from the screen instead of an API integration?
A screen-scraping robot breaks with every portal update and is fragile by nature. When the platform offers an API — as SASCAR, Autotrac, Omnilink and Onixsat do — the right path is system talking to system, through the official door. It's more stable, faster and doesn't depend on anyone having the window open.