How In-Vehicle APIs Are Rewriting the Software DNA of Modern Cars

A Deep Dive into the Role of API-Centric Architectures in Shaping SDV Platforms. How modern automotive leaders are leveraging in-vehicle APIs to accelerate innovation and redefine go-to-market speed.

0. Introduction

In the software-defined vehicle (SDV) era, in-vehicle APIs have become the hidden engine behind innovation, modularity, and speed. These interfaces unlock vehicle functionality as reusable services, enabling automakers to transform vehicles from static machines into dynamic software platforms.

Image generated with Gemini - Nano Banana

1. From Signals to Services: The Rise of Vehicle APIs

Historically, vehicle software was tightly coupled to hardware—custom integrations were needed for every new feature. With APIs, developers now access vehicle functions (e.g., speed, lighting, HVAC) through standardised commands, drastically reducing complexity.

• APIs bring modularity, enabling rapid feature additions.

• OEMs can standardise interfaces across models and tiers.

• A common abstraction reduces cross-team friction in software development.

This shift parallels the smartphone ecosystem, where unified APIs enabled a massive developer ecosystem and software innovation [11].

2. Anatomy of In-Vehicle APIs

In-vehicle APIs are layered to support different roles within vehicle architecture:

• Application APIs: High-level user-facing interfaces like seat control or ADAS configuration.

• Middleware APIs: Handle routing, pub-sub communication, and service discovery across domains.

• Transport APIs: Provide reliable, deterministic communication using SOME/IP, DDS, or custom transports.

The Vehicle Abstraction Layer (VAL) is the key enabler here—it provides developers a consistent way to read/write vehicle signals and trigger behaviours [3]. VAL is getting modernised with more platforms & protocol-agnostic names and strategies.

Vehicle API Layers

3. Welcome Experience: Coordinated by APIs

Here’s how a basic driver welcome sequence becomes trivial with in-vehicle APIs:

vehicle_api.set(”Vehicle.Cabin.Lights.Dome.IsOn”, True)
vehicle_api.set(”Vehicle.Cabin.Seat.Row1.DriverSide.Position”, “profile_2”)
vehicle_api.set(”Vehicle.Cabin.HVAC.Temperature”, 22.0)

• A single function call replaces layers of signal decoding.

• Easy orchestration of multi-domain actions.

• Scalable across car models due to abstraction.

Modern API based approaches enable feature implementation to be shrunk to less than 8 weeks from a traditional 24-week timeline. This makes nimble feature roll-out to the user, enhancing the vehicle ownership experience.

Automotive API within the Vehicle Architecture [Source: www.tietoevry.com]

4. Automotive API Standards: VSS, CAAM, AUTOSAR

To enable cross-OEM standardisation, various bodies have proposed structured data and interface specifications:

• COVESA VSS: Defines a hierarchical structure for vehicle signals like Vehicle.Speed and Cabin.Seat.Position. [1][2]

• CAAM (China Association of Automobile Manufacturers): Defines over 290 atomic APIs for functions across body, powertrain, and comfort domains. [10]

• AUTOSAR API Gateway: Bridges VSS-style abstraction with legacy embedded platforms. [9]

5. Ecosystem Implementations: KUKSA, VISS, AUTOSAR

Turning standards into running code, several implementations support real-world API usage:

• KUKSA.VAL: gRPC broker with support for VSS-compliant data access and pub-sub streaming [3].

• VISS: REST/WebSocket API for accessing vehicle data over web-friendly protocols [1].

• AUTOSAR Adaptive: Defines standardised service definitions and APIs in ARXML format [9].

KUKSA Databroker

6. The Diagnostic Layer: Service-Oriented Vehicle Diagnostics (SOVD)

As vehicles add containers and microservices, legacy diagnostic protocols (like UDS) fall short.

SOVD, standardised by ASAM, enables:

• REST-like access over HTTP for diagnostics.

• OAuth2-based secure access control.

• Dynamic discovery of new diagnostic endpoints.

For example, an OTA diagnostic system can request:

GET /vehicle/diagnostics/faults

And receive structured JSON data without needing ECU-specific UDS commands.

SOVD supports in-car, remote, and hybrid diagnostic models and can bridge UDS for backward compatibility [14].

7. Real-World SDV Companies & API Strategies

Tesla

• Offers over 80 API endpoints to control and query vehicle systems [4][5].

• Recently launched monetised Fleet API [4].

• Uses streaming architectures for real-time updates.

These are primarily REST-based APIs & SDK for developers outside the car. The assumption is that they have equivalent in-car APIs. Tesla might also have a large API set, which is only accessible to internal developers.

BYD

• DiLink OS allows deep in-car app integrations [6].

• D++ platform (semi-open) exposes infotainment APIs via Android SDK [6].

• Limited openness beyond the Chinese ecosystem.

Xiaomi

• HyperOS spans phones, smart homes, and cars [7].

• Prioritises unified software experience across the user ecosystem.

• Leverages API thinking from its IoT products.

Huawei

• Supplies smart cockpit platforms and an autonomous stack to partners [7].

• Emphasises API-based platform delivery, not end-customer ownership.

Changan

• SDA platform with over 500 atomic and 200 scenario APIs [9].

• Designed around Global SOA with reusable service buses and real-time cross-domain middleware.

8. Business Benefits of API-Centric Design

Direct Impact

• 30%+ gain in development velocity due to reuse and modularity [9].

  • One API tested. validated & released once, can be reused for multiple applications & use cases.

• ~14 months to market vs 3-5 years for traditional vehicles [9].

• Reduced recall costs with software-based issue resolution [11].

Strategic Value

• Supports OTA services and subscription features.

• Opens path to third-party developer ecosystems.

• Enhances data monetisation strategies (usage-based insurance, fleet ops, etc.) [11].

Modern SDV automakers make every capability in the car an API. These abstracted APIs enable to delivery of complex functions to the customers.

9. API Thinking vs. Legacy Thinking

API-thinking is more than a technical design choice—it is a mindset shift in how we conceive and deliver vehicle functionality. Instead of designing monolithic, hardware-bound features, engineers break down vehicle capabilities into reusable, discoverable, and composable services. This allows teams to think in terms of contracts rather than implementations: as long as the API remains consistent, underlying systems can evolve independently.

For business leaders, API-thinking means faster innovation cycles, cleaner integration with partners, and a foundation for new revenue models such as feature subscriptions and developer ecosystems. In practice, it turns vehicles into living platforms—capable of adapting and growing throughout their lifecycle, just like smartphones and cloud systems.

10. Open Source Ecosystem: Accelerators and Friction

Key Projects

• Eclipse KUKSA: VSS runtime stack [3].

• Velocitas: App SDKs for SDVs [3].

• uProtocol: Messaging layer between vehicle domains [13].

• SOAFEE: Edge-cloud blueprint for microservices on vehicle HPC [12].

Challenges

• Licensing models (e.g., Eclipse vs. GPL).

• OEM reluctance to open sensitive IP.

• Integration complexity with legacy toolchains [13].

Open source remains a strategic enabler for agile SDV development, especially as software-defined control becomes the dominant value layer.

APIs are strategic; it is part of the DNA. That means, it shall be part of the culture.

11. What’s Ahead: Interoperability and Governance

• Push from COVESA, CAAM, and AUTOSAR for harmonised APIs [1][10].

• ISO/SAE groups exploring API safety and certification pathways [14].

• Edge compute orchestrators (like Eclipse Ankaios) are expanding to support multi-runtime SDV stacks [13].

Conventional OEMs struggle to think about software-first or API-first, as they are culturally mechanical & efficient in creating brittle one-to-one interfaces. A full thought process change is imminent to achieve SDV and an API-first approach. This is a similar moment when modern software moved from a monolith to microservices.

Image Generated with Gemini - Nano Banana

References

1. COVESA Vehicle Signal Specification – https://covesa.github.io/vehicle_signal_specification/

2. Intellias: Vehicle Signal Specification – https://intellias.com/vehicle-signal-specification/

3. Eclipse KUKSA Databroker – https://github.com/eclipse-kuksa/kuksa-databroker

4. Tesla API Developer Guide – https://www.linkedin.com/pulse/tesla-opens-its-api-high-octane-move-marketers-exnovation-n9ztc

5. Shankar Kumarasamy: Tesla API Documentation – https://shankarkumarasamy.blog/2023/11/23/tesla-developer-api-guide-developing-third-party-apps-part-2/

6. Wikipedia: BYD Automotive OS – https://en.wikipedia.org/wiki/BYD_Auto

7. ResearchInChina: Xiaomi HyperOS Overview – http://www.researchinchina.com/Htmls/Report/2024/73953.html

8. Business Standard: Huawei Smart Driving Strategy – https://www.business-standard.com/world-news/here-s-why-huawei-s-expansion-in-smart-driving-stirs-competition-scrutiny-125042300138_1.html

9. ResearchInChina: SDV Middleware Platforms – https://www.marketresearch.com/Research-in-China-v3266/Software-Defined-Vehicles-SOA-Middleware-40596367/

10. CAAM Automotive Open Standards – http://en.caam.org.cn/Index/show/catid/22/id/1565.html

11. TietoEVRY: Automotive API Adoption – https://www.tietoevry.com/en/blog/2025/10/introduction-automotive-api/

12. Arm SOAFEE Overview – https://www.arm.com/company/success-library/made-possible/soafee

13. Eclipse uProtocol GitHub – https://github.com/eclipse-uprotocol

14. IEEE: SOVD Implementation Framework – https://ieeexplore.ieee.org/document/10620563/

This blog is edited and enhanced with Perplexity, ChatGPT & Gemini