Vehicle Telematics API Integration and Maintenance: Hidden Costs and Difficulties

Shared mobility operators are diversifying their fleets to differentiate themselves and meet customer demand in a competitive market. However, connecting different vehicle models to get useful data can be difficult. Developers need to create and manage API integrations to pull data from aftermarket telematics hardware or from vehicles’ OEM telematics units. Fleet operators often underestimate the related difficulties and costs because they’re unaware of the “hidden” challenges of working with APIs. Let’s shed some light on these pains that many in the industry stumble upon unaware.

• Definition of API and their role in a connected fleet
• Difficulties in maintaining multiple API’s
• Relationship with API support teams
• Learning curve with API’s and the alternatives

Telematics APIs overview

First, a very brief overview of what APIs are and of their role in a connected fleet. APIs, or Application Programming Interfaces, are software that serve as connections between two applications. In connected fleets, they connect vehicle telematics hardware with fleet management software, client-facing software, and other services like charging infrastructure or field services software.

However, different telematics solutions “speak” differently; data values for fuel levels in BMWs and Fords, for example, may be different. In fact, even basic data values may be different across different vehicle models from the same manufacturer. This causes integration difficulties for operators who want to add vehicles with telematics unlike the ones already in their fleet. Additionally, new telematics features and updates require ongoing maintenance of the API integrations. These integration and maintenance tasks can take up a lot of valuable developer resources.

Difficulties with maintaining more than one API

Integrating and maintaining one API may be hard enough, but as soon as developers for connected fleets need to handle more than one, the task gets even more complex.

Different telematics APIs might handle various basic data values differently; each one needs its own investigation, testing, and code implementation to integrate correctly with software. Some differences can include:

• Value of either “true” or “false” for locked doors
• A request to lock a door may be confused with a status report that a door is locked
• The “door lock status” may refer to all doors or to just the driver’s door
• Odometer reading can be reported in kilometers or in miles
• Odometer data value can be named “odometer” or “mileage”
• Different ways of handling timestamps and time zones

“Null” values can be another big source of confusion. For example, a null value for the door lock status could mean different things in different APIs:

• Unknown door lock status
• It’s not possible to know the door lock status in this system
• The door lock status is not known at the moment but may be known later

API documentation difficulties

Managing APIs is hard enough with good technical documentation, but we often see it fall short. Insufficient and inaccurate documentation causes developers grief when they realize that the telematics behaves other than expected.

While in some cases important documentation may be missing, in other cases unnecessary info may be clogging up the manual. One OEM documents how to pull data on the number of radio stations stored in vehicle memory, for example. Shared mobility and connected fleet clients don’t need to understand all the data that’s available via APIs.

To add to developers’ frustration, while the documentation might tell users all that the API can do, not all of it will necessarily work with all documented vehicles. There may be differences between vehicle models, or generations of the same model, which the documentation can fail to consider.

Relationships with API support teams

Good client support may ease many of the problems above, but here too we see many operators fail to foresee problems.

Despite our modern, connected world, time zones are still a barrier to communication between some companies. An operator in California may have to wake up early and still have only an hour to virtually meet a European OEM support team, for example. This tends to result in asynchronous communication and days to resolve even simple problems. Possible language differences may make those communication problems even worse.

In our experience, it helps greatly to have a pre-existing relationship with key API contacts at OEMs. Those relationships are particularly useful for warning operators of upcoming changes and feature additions to APIs and protocols. These changes may happen as often as monthly for car OEMs who are new to the API business, and can cause nasty surprises if operators aren’t warned and don’t make necessary changes to their code beforehand. However, it takes time to develop these kinds of relationships, so operators for newly connected fleets often lack them.

Beware the learning curve and know the alternatives

A lack of experience with integrating and managing APIs means that progress can be slow, especially initially. For example, it took our dedicated team at INVERS up to three months to implement new API connections at first. After a lot of learning, we have cut this time down drastically.

Why not take advantage of what we learned and use us to implement and manage your APIs instead of climbing the steep learning curve yourself? Contact us to learn how OEM Integrations can aggregate, clean, and standardize data from vehicles in your fleet.