FleetSQL 
FleetTAB 
Ecodriving 
Maintenance 
Fleet Config 
Logbook 
Utilization 
Merger 
Routly
Every fleet we work with has a number Wialon never sees. The cold-chain probe knows the trailer ran at −18 °C. The weighbridge knows the truck left with 24 tonnes on it. The ERP knows the job was delivered at 14:02. All of it sits in a system the customer already pays for, and none of it can become a Wialon sensor, a report column or an alert — because a Wialon unit binds to exactly one tracking device, and that device’s protocol is the only way in.
Message Merger is our answer to that. It takes a webhook from any system, maps its fields onto Wialon message parameters, and writes them onto a unit that keeps its real tracker. The Message Merger product page has the feature breakdown; this is what it is for.
What a customer actually connects
| What sends | What lands on the unit | What Wialon can then do |
|---|---|---|
| Cold-chain probe | cargo_temp, door_open | A temperature sensor, a trip report column, an alert when it rises |
| Weighbridge or load cell | load_kg | Axle-load trends per vehicle, an alert over the legal limit |
| ERP or dispatch system | job_id, delivered_at | The job on the same timeline as the movement that served it |
| Driver app or third-party API | whatever it holds | A value the fleet already owns, in the reports it already runs |
The pattern is always the same: a system that knows something about the vehicle, and a Wialon account that cannot ask it. The value is not new data — the customer has it. The value is that it finally lands where the reports are.
It becomes a real sensor, not a dashboard beside one
This is the part that decides whether the integration is worth anything. A parameter on a unit is not a screen we drew: it is a Wialon message parameter, so a Wialon sensor binds to it by name and everything downstream reads it.
We proved that on a live account on 12 August: a temperature sensor bound to cargo_temp rendered the reading as −18.40 °C, on a unit that kept its real tracker and its own history. Not a number we displayed — a number Wialon displayed, because by then it was Wialon’s.
From there nothing is special any more, which is the point:
- Reports render the values as their own rows, so a delivery report can carry the temperature it ran at.
- Notifications fire on a range, so an excursion becomes an alert to the same people who already get the speeding ones.
- The mobile apps and the customer’s own exports read it, because it is a sensor like any other.
Each sender gets its own endpoint
A system that sends is set up once: its own URL, its own secret, and a mapping that says which value in its JSON becomes which parameter on the unit. Adding a second sender changes nothing for the first, and nothing about the sender’s own format has to change for Wialon’s sake — the mapping absorbs grams, millivolts and Kelvin on our side.
Writing that mapping is a conversation with us, not a project for your developers. What it looks like field by field is in the guide.
The tracker stays exactly where it is
The usual route for this problem is a second platform in the path — merge the streams in flespi and feed Wialon one combined virtual device. Merger takes the other route: the unit’s device type does not change, the tracker keeps reporting as it always did, and the extra readings land beside its messages on the same unit. No second vendor, no second bill.
What it does not do
An honest limit, because it decides whether this fits your case at all. Readings arrive in seconds, not milliseconds. If a value has to trigger an alarm the instant it changes — a panic button, a door opening on a secured load — this is the wrong path and flespi is the right one, and we build on that stack too. If it is a number that a report, a claim, a customer SLA or a compliance record has to contain, the delay costs nothing and saves a platform.
How to get one
Merger is in preview rather than on general release. We stand the endpoint up against your account, configure the first sender with you and hand over the admin app that shows what each hook is doing — what has been buffered, imported and retried.
It is priced per application under your own brand, like the rest of the Marketplace set on our products page: your logo, your domain, your commercial relationship with the customer.
Wialon third-party data FAQ
Does the vehicle need a second device fitted?
No. The data comes from a system that already exists — a probe, a weighbridge, an ERP — over HTTP. Nothing is installed on the vehicle and the tracker is untouched.
Which systems can send to it?
Any that can make an HTTP request, which in practice is all of them. If the system cannot be made to call out at all, the middle ground is a scheduled job on your side that reads it and posts on its behalf.
Can it write to any Wialon unit?
Yes, on any device type, including a unit that already has a live tracker on it. That is the whole reason the service exists.
Does the data pass through your database?
No. A reading is buffered only until its batch is written to Wialon, and what fails is kept so it can be replayed rather than lost silently. The record lives in the customer’s Wialon account, not in ours.
Can we resell it to our own customers?
Yes — under your brand and domain, with the pricing and the relationship yours.
Getting started
Tell us the system that holds the data and the unit it belongs on, and we will map its fields onto Wialon parameters with you — it takes a conversation, not a project. The Message Merger product page has the detail, and a note here reaches us directly.
