What data can automotive apps actually access?
Modern vehicles generate data constantly. Speed, steering angle, throttle position, battery state, tyre pressure, cabin temperature, GPS coordinates, driver attention scores, all of it flowing through dozens of electronic control units, producing thousands of data points per second. The reasonable assumption, when you sit down to design an automotive app, is that this data is broadly accessible. Build the interface, call the API, pull the feed. The reality is considerably more complicated than that.
Access depends on who made the vehicle, which model year it is, which market it was sold into, what agreements exist between the manufacturer and any third-party developer, and which regulatory frameworks apply in the territory where the user is driving. What is technically possible and what is legally permissible are two very different things, and the gap between them has caught more than one product team by surprise partway through a build.
GDPR, CCPA, and the regulatory frameworks that govern in-vehicle data
Vehicle data falls squarely within data protection law wherever it relates to an identifiable individual. Location history, driving behaviour, biometric signals from driver monitoring cameras, and any data linked to a registered keeper or habitual driver all constitute personal data under GDPR in the UK and EU, and under CCPA in California. The obligations that follow are substantial.
Controllers must identify a lawful basis for processing. Legitimate interest, consent, and contractual necessity each have different implications for how data can be collected, stored, and shared. For in-vehicle apps, consent is often the most defensible basis, but meaningful consent in a moving vehicle raises its own challenges around distraction and the quality of informed agreement a driver can give while operating a vehicle.
Data minimisation is a core GDPR principle that creates tension with the instinct to collect everything and decide later. An app that captures full GPS traces, cabin audio, and driver attention scores because those signals are technically available faces a significant compliance burden justifying each category of collection. The question to answer before building is not "what can we capture" but "what do we specifically need, and what is our documented basis for each element."
Map every data category your app touches against a specific lawful basis before writing a line of collection code. Retrofitting this later, after the architecture is set, is far more expensive than doing it at the design stage.
When API limitations force a pivot: lessons from locked-down platforms
On the production management product for the motion picture industry, we had designed the data ingestion approach around direct integration with the platforms the industry already used to store production documents. The assumption was that documented integrations existed and that we would be able to access them. When we finally had credentials and were inside the systems, we found they were far more secured than the documentation implied, and the access we needed simply was not there.
The pivot was to ingest emails tied to specific roles within a production, effectively reading the data that flowed through the communication layer rather than through the document storage layer. It worked, but it was a different architecture from the one we had planned, and arriving at it after the original design was already committed meant rebuilding a portion of the product under time pressure.
The equivalent in automotive development is assuming that because an OEM offers a developer programme, that programme will expose the specific signals your product needs. The gap between what the programme markets and what the API actually returns is often significant. The only reliable way to verify what you can actually use is to get API credentials and test what is available before committing to a product architecture that depends on signals you have not yet confirmed you can access.
Request API credentials and run tests against real endpoints before any architecture decision that depends on a specific data signal. Documentation describes intent, not always reality.
Type approval, functional safety, and the standards that govern in-vehicle software
Software that runs inside a vehicle and interfaces with systems involved in vehicle control operates in a different regulatory environment from a consumer mobile app. Type approval, the process by which a vehicle is certified as meeting regulatory requirements before it can be sold, now includes provisions for software, and changes to approved software configurations can require reapproval depending on the jurisdiction and the nature of the change.
ISO 26262 is the functional safety standard for road vehicles. It defines a risk-based approach to software and hardware development, classifying systems according to their Automotive Safety Integrity Level and setting development process requirements accordingly. An app that touches active safety systems, or that could affect vehicle behaviour if it fails, sits within scope of this standard. The development, verification, and documentation requirements are substantially more demanding than those for a consumer mobile product.
UN Regulation 155, which came into force for new vehicle type approvals in Europe in 2022, introduces mandatory cybersecurity management system requirements for connected vehicles. Software updates, data transmission, and third-party software integration all fall within its scope. A third-party app that reaches into vehicle systems needs to account for how it interacts with the manufacturer's obligations under this regulation.
- ISO 26262, functional safety for automotive electrical and electronic systems
- UN Regulation 155, cybersecurity management system requirements for connected vehicles
- UN Regulation 156, software update management system requirements
- GDPR / UK GDPR, data protection obligations for personal data generated by or about vehicle occupants
Why compliance gaps discovered late cost far more than those caught early
The peer-to-peer currency exchange product we worked on is the clearest illustration of what late compliance discovery costs. The product allowed users to exchange leftover foreign currency with other travellers at interbank rates. The core transfer mechanism worked well. What we did not factor in was anti-money laundering requirements. Apple flagged the product as a potential vehicle for money laundering because of its unlimited transfer capability.
Going back to retrofit compliance meant adding more stringent KYC checks, enhanced transfer security, and hard limits on the number of transfers permitted between any two parties. That was architecture that should have been part of the original design, and discovering its absence at the point of App Store submission made it substantially more expensive than it would have been had it been identified during the design phase.
The dating app project produced the same lesson from a different angle. The client chose to skip discovery on the messaging component and focus only on onboarding. The result was a generic messaging feature that allowed automated and fake messages, directly contradicting the verified-profiles premise the entire product was built around. The section had to be rewritten at a cost of approximately £15,000 in additional budget and two months of extra work. Compliance and design coherence both follow the same rule: the cost of correcting something grows the later in the build it is discovered.
Schedule a specific compliance review at the point of data architecture design, before any build begins. Anti-money laundering, KYC requirements, and data minimisation obligations are all far cheaper to design in than to retrofit.
How to map data access realistically before committing to a product architecture
The practical approach is to treat data access as an assumption that requires validation, not a given that can be confirmed later. Before any architecture decision is made around a specific vehicle signal, the team needs to know that the signal is accessible via the intended route, at the intended fidelity, in the markets the product will operate in.
This means getting API credentials early, running tests against real endpoints, and documenting what is actually returned rather than what the developer documentation describes. For OBD-II based approaches, it means testing with the specific vehicle models and years the target users are likely to drive. For OEM developer programmes, it means understanding the full terms of access, including what the manufacturer can modify or withdraw and under what notice period.
| Data source | Typical access route | Reliability risk | Regulatory consideration |
|---|---|---|---|
| OBD-II port | Third-party hardware dongle | Low, standardised protocol | Personal data if linked to an individual |
| OEM connected car API | Manufacturer developer programme | High, subject to policy change | Data processing agreement required |
| CarPlay / Android Auto | Apple / Google SDK | Moderate, platform rules apply | Platform terms restrict data capture |
| CAN bus direct | Hardware with OEM cooperation | High, requires manufacturer agreement | May trigger UN Reg 155 obligations |
On the memory-sharing proof-of-concept project, switching from Spotify to Deezer resolved both a technical and a compliance problem simultaneously. Working with Spotify without a proper API would have required significant workarounds and custom-built solutions to stay within their rules. Using Deezer's official API in the way Deezer intended meant the team was fully compliant without needing those workarounds, and the architecture was simpler as a result. The lesson is that the path of least resistance is usually the path of working within the boundaries a platform sets, rather than trying to route around them.
Conclusion
The question of what automotive apps can actually access has a genuinely complicated answer, and it varies by manufacturer, model year, territory, data type, and how the app connects to the vehicle. The honest version of that answer is that far less is freely accessible than the technical capability of modern vehicles implies, and the frameworks governing what you can legally do with accessible data add a further layer of constraint on top of that.
The projects that run into trouble are the ones that treat data access as a detail to be confirmed later, after the architecture is already committed. We have seen the cost of that assumption across multiple product categories, and automotive is one of the areas where discovering a gap late is particularly expensive, because the compliance landscape is more demanding and the remediation options are more limited.
Starting with a realistic map of what is actually accessible, via which route, under which terms, and subject to which legal obligations, is the work that protects the rest of the build. It is less interesting than designing the interface, but it is what determines whether the interface ever ships in the form it was designed.
If you are scoping an automotive or connected vehicle product and want to think through data access realistically before committing to an architecture, let's talk about your product.
Frequently Asked Questions
Modern vehicles produce thousands of data points per second, covering everything from speed, steering angle, and throttle position to GPS coordinates, tyre pressure, and driver attention scores. All of this flows through dozens of electronic control units, making vehicles extraordinarily data-rich environments. However, generating data and being able to access it as a third-party developer are two very different things.
Yes, GDPR applies wherever vehicle data can be linked to an identifiable individual, which covers a wide range of signals including location history, driving behaviour, and biometric data from driver monitoring cameras. Controllers must identify a lawful basis for processing each category of data they collect. Failing to do this before building can result in significant compliance problems that are costly to fix retrospectively.
Consent is often the most defensible lawful basis for in-vehicle apps, though legitimate interest and contractual necessity are also options with different implications. The challenge with consent in a vehicle context is that obtaining meaningful, informed agreement from a driver while they are operating the vehicle raises genuine concerns about quality and distraction. Product teams should think carefully about when and how consent is gathered, ideally before the vehicle is in motion.
Data minimisation is a core GDPR principle that directly conflicts with the common instinct to capture everything available and decide later what is useful. Each category of data an app collects requires a documented justification, so capturing full GPS traces, cabin audio, and attention scores simply because they are technically accessible creates a substantial compliance burden. The right question to ask at the design stage is what data is specifically needed, not what data can be reached.
Many manufacturers do offer developer programmes, but the signals exposed through those programmes often fall short of what a product actually requires. The gap between what is documented and what is genuinely accessible once you are inside a system can be significant, and discovering this mid-build forces expensive architectural changes. Validating real API access and testing against actual credentials before committing to a design is strongly advisable.
Access depends on a combination of factors including the vehicle manufacturer, the model year, the market the vehicle was sold into, and the agreements in place between the OEM and any third-party developer. Regulatory frameworks in the territory where the driver is located also play a role, meaning a data feed that is permissible in one country may not be in another. What is technically possible and what is legally permissible are frequently not the same thing.
Teams that discover access limitations mid-build often have to pivot to alternative data sources, which can mean a substantially different architecture from the one originally designed. The article gives the example of switching from direct document storage integration to ingesting data through an email communication layer when the primary route proved inaccessible. Arriving at that kind of workaround under time pressure, after the original design is already committed, is significantly more expensive than discovering the constraint earlier.
Mapping every data category against a specific lawful basis should happen before any collection code is written, ideally at the earliest stages of product design. Retrofitting compliance decisions onto an architecture that is already built is far more costly in time and resource than addressing it upfront. Treating this as a design activity rather than a legal afterthought protects both the product and the development budget.