In August, alongside the launch of Gurtam’s new data center in Saudi Arabia, the product team also updated the connection between Wialon and WASL, which gives partners in the country a way to connect vehicles to WASL not only through Wialon Local but also through the cloud products in the Wialon suite.
For TSPs in Saudi Arabia, this is more than a useful integration; it is a necessity. Companies operating in multiple transport segments are required to submit vehicle-tracking data to WASL, a system that makes transport data available to government authorities. In this case, integration is part of the basic infrastructure needed to operate in the market.
The WASL case is not an exception. It fits a broader pattern in aftermarket telematics, where the challenge for telematics software providers is shifting from a relatively straightforward one – making software compatible with as many devices as possible and covering the basics of vehicle monitoring – to a more complex one: combining different data sources and services.
Telematics data increasingly moves between systems rather than staying inside a single platform: it may originate in a GPS device, an OEM, or another connected-vehicle service, pass through a telematics platform, and then be used by regulators, tolling systems, insurers, logistics software, or the customer’s own infrastructure. Fleet Europe recently pointed to the same shift in the industry: as fleet management becomes more complex, the value of telematics increasingly depends on how well data from vehicles, OEMs, fleet platforms, and third-party tools can work together.
As a GPS software company, Gurtam has been moving in this direction for years, building products designed not only to work with a broad range of hardware but also to exchange data with the wider telematics ecosystem. The way this works varies by product, and that is where integrations come in.
What we mean by pre-built integrations
Before going further, it helps to clarify what we mean by "integration" here. The terminology is not especially consistent across telematics: one company may call something a connector, another a retranslator, a partner integration, or simply an integration. The same word can describe anything from a one-off connection built for a single customer to a service maintained as part of a product.
For this article, we use pre-built external integration for the latter: a connection to an external system that addresses a repeatable market need and is maintained for use by multiple customers or partners. This is different from a customer-specific integration, built around a single deployment or workflow, and from an integration partner, which refers to the company performing the integration rather than the connection itself. A retranslator, meanwhile, is best understood as one technical type of integration, rather than a separate category at the same level.
Obviously, when requirements repeat often enough, are important to a particular market, and carry clear business value, it makes sense to solve them once and maintain the connection as part of the product.
They tend to fall into a few broad groups:
-
Regulatory reporting: vehicle data must be sent to a government system.
-
Tolling and transport infrastructure: telemetry is used to calculate, declare, or settle road use.
-
External business services: insurers, maintenance platforms, TMSs, and other systems need access to fleet data.
-
OEM and external vehicle-data sources: the telematics platform receives data from another system rather than directly from an aftermarket device.
What these integrations have in common is not a particular architecture or approach: a pre-built integration may be a relatively simple telemetry retranslator, a connector that synchronizes several entities between systems, or an integration that brings an external data source into the managed platform. What makes it pre-built is the repeatability of the need, not the way the connection is implemented.
From WASL to High Mobility: how integrations differ across Gurtam products
Pre-built integrations exist across Gurtam products, but they are not approached in exactly the same way. That largely comes down to what each product is built to do, who uses it, and where it sits in the data flow.
For Wialon, integrations are closely tied to the needs of its partner ecosystem. With around 2,700 partner companies serving fleets in different markets, many of the recurring requests are practical ones: comply with a local regulation, connect a customer to a service they already use, or bring another source of vehicle data into Wialon.
This is the playground for integrations such as WASL and SENT, as well as e-Track for tolling and more extensive service integrations like SpeedGauge. Wialon can also exchange data with external business systems such as Fleetio, while integrations via flespi enable integration with sources such as High Mobility and other OEM platforms.
flespi, as telematics middleware, has a different role by design: it sits between data sources and the systems that need that data, supporting integrations in both directions — upstream and downstream. Upstream, data can come from GPS hardware, OEM clouds, or other telematics platforms and be normalized inside flespi. Downstream, the same data can then be forwarded to another telematics platform, a regulatory or tolling system, a cloud service, or a customer application.
High Mobility is one example on the upstream side, while SENT-GEO and e-Toll are examples of downstream integrations. And when there is no dedicated pre-built connection, generic mechanisms such as MQTT and HTTP provide other ways to exchange data. This makes flespi particularly useful as an integration layer between systems that were not originally designed to communicate with one another.
GPS-Trace approaches the same problem from the perspective of a more focused product and partner base. The SUTRAN retranslator in Peru is a good example: a regulatory requirement that repeatedly matters to local partners becomes a capability available directly in the product, rather than something each provider has to develop independently.
There is also connectivity within the Gurtam ecosystem. Data does not have to remain in the product where it first arrives: depending on the use case, it can move between GPS-Trace, flespi, and Wialon, allowing the products to play different roles in the same data chain.
Taken together, these examples show why it is difficult to describe Gurtam integrations through a single technical model. What remains consistent is the aim to avoid making the product boundary a hard boundary for the data.
No integration catalog can cover every customer stack
Pre-built integrations can cover recurring needs, but no integration catalog can cover every customer stack. Every business works with its own mix of platforms, data sources, services, and internal systems, so there will always be connections that are too specific to make sense as a product-level integration.
That is why Gurtam also provides an open integration layer. Depending on the product, customers, partners, and integrators can use APIs, SDKs, protocols, streams, and other mechanisms to build the connections their own technology stack requires. The distinction is simple: pre-built integrations solve recurring needs; open integration tools allow customers and partners to solve specific ones.
From the early days of Gurtam, supporting a broad range of devices was a practical choice: customers and partners needed the freedom to use the hardware that suited their market and business. The same principle applies to the rest of the technology stack. Pre-built integrations and open integration tools give them more choice not only at the source of telematics data, but also in where that data goes and what they can do with it.
