In The Adventure of Silver Blaze, Sherlock Holmes solves the case by focusing on a detail everyone else overlooked: the guard dog didn’t bark during the night. A dog’s silence seemed trivial, but to Holmes it was the key – because a guard dog should bark at an intruder. Its failure to act revealed that the culprit was someone the dog already knew. Holmes cracked the mystery by paying attention not to what happened, but to what conspicuously didn’t.
What conspicuously didn’t flespi accomplish during this year that has almost come to an end? As declared a year ago, flespi planned to proactively implement integrations with OEM data providers. We integrated volvo-trucks and renault-trucks API, remastered our integration with Fleetboard (which is responsible for Daimler trucks) – so it was all about commercial trucks. But there was no news about flespi integrated with any light vehicle manufacturer: Toyota, Volkswagen, and BMW passed by flespi without a stop. Why? It turned out to be harder than we thought. An attentive reader of our blog might reasonably argue that for this "dream team" of top-level engineers, nothing can be too hard: remember that we have a state-of-the-art AI assistant handling 90% of customer communication and prepare to hit the 1.5 million connected devices mark within a month (with a team of 10 people). Indeed, the difficulty is not in the engineering. It is in… legal matters :)
Driver’s consent
When we speak about trucks, they are pure commercial vehicles: owned by companies, sold by huge enterprises, moving cargo of corporations, covered by insurance of legal entities. It is B2B2B2B – businesses all the way down. A driver has a contract with one of the businesses where data usage consent is given automatically, even before they get a heavy-vehicle driving license. But with light vehicles, the situation is different. They are naturally mostly owned and driven by regular people, which is reflected in the OEM’s data provider’s policy. Driver’s consent must be taken and stored for a certain period of time, and prepared for an audit check. Each OEM has its own rules and policies. Just reading and comprehending them all requires a lot of intense legal work. And we haven’t even started thinking about the technical implementation yet. Telematics is the main focus for flespi, not the doc-flow.
Contract with OEM
If you are a flespi customer, you know that you work with flespi based on a public contract. It is as public as possible; you may literally see it here. It is common for all countries (except for those under EU sanctions), legal entities, and tariff plans. If you need the price, we don’t ask you to contact us; we give you the pricing. That’s not the way it works with big corporations that sell big numbers of vehicles. Contracts are complex, different, with a lot of obligations, clauses, cases, and exceptions. Just reading and crafting the contracts requires a lot of intense legal work. Fulfilling the obligations might be even harder and more expensive than crafting the contract. And even before getting there, you need to prove that you are a serious company with a long history and many potential customers willing to work with OEM data.
Different data availability plans
Yes, telematics is getting more complex. Yes, CAN bus contains a lot of data which can be used to extract business value: engine, DTCs, fuel, and/or battery data. It is digital gold, but if you are on the aftermarket side, the only thing left for you is reverse engineering. That is not a problem; people build businesses on top of it. But nobody is closer to the vehicle's original data than the manufacturer. When you get left front wheel tire pressure from an aftermarket telematics device it might be left front wheel tire pressure or the random value in the register responsible for it on the device, or you incorrectly selected vehicle's modification and there is an error in the appropriate library: interesting and funny quest you need to pass with each new vehicle model and even make year. When you get the left front wheel tire pressure from the OEM data service, you are sure that it is the left front wheel tire pressure. And if it is not, your legal department may sue the OEM data service provider for violation of contract obligations, good luck with that :) Jokes aside, the OEM knows exactly what data is available on what terms for each of their manufactured vehicles. This is guaranteed. It is a stable and predictable way to do business. OEM manufacturers give their customers control over what data points from what vehicles to retrieve, which adds enormous complexity to configuring this service. All the data points are spread across different pricing plans, which are different for each manufacturer. Just calculating how this amount of variability will be reflected in our contract with the customers who will use it requires a lot of intense legal work. That said, all this variability must be integrated into our services.
High Mobility solved it all
High Mobility started in 2013 and later settled in Berlin. From the beginning, the team pushed toward a simple idea: give developers a unified gateway into official OEM data instead of forcing them to juggle a dozen separate integrations. Over the years, they lined up solid partners, ran early UX prototypes through BMW Startup Garage, attracted investment from DAT (Deutsche Automobil Treuhand), and scaled the platform to support 20+ automotive brands with well over a hundred million data updates flowing in daily. On the compliance side, they keep things tight with ISO 27001, GDPR, and TISAX – a must-have security pack when you’re dealing with factory-grade telemetry.
Some of their headline collaborations include Mercedes-Benz, where High Mobility taps OEM data straight from the source – no retrofit hardware needed. For flespi, High Mobility is an OEM-grade data pipe in the toolkit: the protocol is fully supported, data lands in unified JSON, and moves downstream via MQTT/REST without any special handling. Just a clean, straightforward piece of the ecosystem – exactly as it should be.
The High Mobility interface lets you pick a brand, model, and the exact data points you need – with cost estimates built right into the selection flow. Helpful hints surface details like update frequency and API type for each data point. As a developer, I can appreciate how much work went into organizing this sprawling matrix of manufacturers, models, and data services into something coherent. Hats off to the High Mobility team for pulling it off.
flespi integration with High Mobility
Hm, if High Mobility is integrated with all OEM data services and provides data via API, the most reasonable question is: Why do I need flespi here? The short answer: you don't. Indeed, if you have a standalone task to integrate OEM data into your system, use High Mobility. We have integrated it as a data source in flespi for the customers that have mixed fleets: aftermarket telematics devices are widely used and already integrated into their system, and they need a fast and easy way to connect OEM data. Instead of implementing a new integration of another 3rd party service into their system, they may utilize flespi's existing integration. If we speak about a more complex task where flespi acts as not only a gateway, but is used for long-term data storage, data transformation, or complex data analytical tasks, then High Mobility is a fast and easy way to inject the data from your vehicle fleet to flespi.