Why AIS-230 API Standard Is the Most Important API Standard Indian OEMs Have Never Heard Of

On August 4, 2026, India’s Ministry of Road Transport and Highways published a draft notification mandating Vehicle-to-Vehicle (V2V) communication in all L, M, and N category vehicles every passenger car, truck, bus, motorcycle, and scooter manufactured after October 1, 2028. The standard is AIS-230. The protocol is C-V2X. The engineering deadline is tighter than it looks.

This is not a future-mobility thought experiment. It is a gazette notification with a compliance date. Every OEM shipping vehicles into India has roughly 24 months to build, test, and certify a connected vehicle telematics stack that most of their software teams have never touched. The engineering bottleneck is not the On-Board Unit (OBU) chipset. It is the API layer that connects that OBU to backend services, to road infrastructure, and eventually to a national V2X data exchange that the government has not finished specifying.

This post covers what AIS-230 actually requires at the API layer, where most OEM engineering teams will misread the mandate, and a framework for scoping the work before your compliance window closes.

What AIS-230 Actually Requires

The MoRTH draft names Cellular Vehicle-to-Everything (C-V2X) as the required protocol, operating in the 5.875 GHz to 5.925 GHz frequency band. The Department of Telecommunications exempted this band from licensing requirements through a separate notification on June 10, 2026, clearing the spectrum path for deployment. TRAI has opened a parallel consultation on the V2X ecosystem which means the regulatory stack is moving in real time.

AIS-230 mandates factory-fitted OBUs that support:

– Vehicle-to-Vehicle (V2V) broadcast: collision warning, emergency braking alerts, blind spot hazard messages

– Vehicle-to-Infrastructure (V2I): traffic signal phase data, road hazard broadcasts, toll infrastructure handshakes

– Vehicle-to-Pedestrian (V2P): proximity alerts for two-wheelers and pedestrians carrying V2X-enabled devices

India is the first country in the world to extend V2V requirements to every motorcycle and scooter. That coverage distinction matters for API design because two-wheeler OBUs operate under tighter power and compute constraints than passenger car units, which changes the message format, the transmission interval, and the backend processing requirements for managing the volume of V2X broadcasts at scale.

The OBU broadcasts Basic Safety Messages (BSMs) at 10Hz. In a dense urban traffic cluster of 50 vehicles within 300 meters, your backend infrastructure needs to process 500 BSM events per second, per cluster, in near real time.

The Four Layers Your V2X API Stack Must Address

AIS-230 is primarily a wireless protocol specification. It does not dictate backend architecture. That is where the engineering judgment comes in, and where shortcuts compound into expensive retrofit projects.

Layer 1: On-Board Message Broker. The OBU must serialize BSMs in the standard J2735 message format and broadcast over PC5 (direct V2V) and Uu (cellular uplink). The firmware API contract between the OBU vendor and your vehicle software stack determines how your powertrain and ADAS systems receive incoming hazard messages. Most OEMs are treating this as an ECU integration task. It is actually an API contract with latency SLAs in the 100-millisecond range.

Layer 2: Telematics Gateway. The cellular uplink connects the OBU to a cloud backend via a telematics gateway. This gateway must handle protocol translation (J2735 binary to your internal event schema), authentication (certificate-based mTLS for V2X as specified under IEEE 1609.2), and routing of incoming V2X messages from national infrastructure. The gateway is where most OEM backends are under-designed: built for diagnostic data polling, not for bidirectional real-time event streams.

Layer 3: National V2X Exchange API. The government’s Intelligent Transportation System infrastructure will eventually publish a national V2X data exchange API. The specification does not exist yet, but the architecture is directionally clear from TRAI’s consultation: a publish-subscribe model for road condition broadcasts, a registry for RSU (Road-Side Unit) endpoints, and certificate authority services for device identity. Your backend must be designed to integrate with this exchange when it publishes, not retrofitted after.

Layer 4: OEM Application API. Above the telematics gateway sits your OEM application layer: the ADAS integration, the in-cabin alerting system, the fleet management dashboard, and the over-the-air (OTA) software update pipeline. Each of these consumes V2X data differently. Your API design must separate the real-time event stream (latency-critical) from the aggregate reporting stream (analytics-oriented) at this layer.

Connected Vehicle API Contract Scorecard (CVACS)

The CVACS is a five-dimension evaluation tool for assessing V2X API readiness. Score each dimension from 1 (not started) to 4 (production-ready):

Dimension 1: Protocol Compliance. Does your OBU firmware implement J2735 message sets and IEEE 1609.2 certificate management? Score 4 if you have a test environment generating and consuming BSMs at spec. Score 1 if your OBU vendor has not confirmed C-V2X chipset availability.

Dimension 2: Gateway Latency Architecture. Can your telematics gateway handle bidirectional V2X event streams with sub-100ms processing latency? Score 4 if you have load-tested at 500 events/second per cluster. Score 1 if your gateway was designed for diagnostic data batched at 60-second intervals.

Dimension 3: Certificate Lifecycle Management. IEEE 1609.2 requires pseudonym certificates that rotate on a time and distance schedule to protect vehicle privacy. Score 4 if you have a PKI integration plan for certificate issuance, rotation, and revocation. Score 1 if certificate management is not yet on your architecture diagram.

Dimension 4: National Exchange Readiness. Has your API design included an adapter layer for connecting to the eventual national V2X exchange? Score 4 if you have built a configurable connector using standard publish-subscribe patterns (MQTT or AMQP). Score 1 if your backend assumes direct OBU-to-application communication with no exchange layer.

Dimension 5: OTA Update Pipeline V2X firmware will require updates as the national standard evolves. Score 4 if you have an OTA pipeline with rollback capability, staged deployment, and delta updates. Score 1 if OTA updates require physical service center access.

A score of 12 or above indicates teams that can meet October 2028 with focused engineering effort. Below 8, you are looking at a foundational rebuild.

We applied an early version of this scorecard at a fleet telematics company serving EV operators across South Asia. Their gateway latency score was a 1: the entire backend was built on a polling model with 15-second intervals. Retrofitting that for real-time V2X event streams required a full message broker redesign, not a configuration change.

>AIS-230 is not a safety feature. It is a 2028 API deadline embedded in a regulatory gazette.

Where Most OEM Telematics Teams Will Get This Wrong

Every OEM that treats the C-V2X OBU as a hardware procurement question will spend 2027 rebuilding the software layer from scratch.

The most common mistake is buying a certified C-V2X OBU from a Tier-1 supplier and assuming the compliance box is checked. The OBU handles the radio layer. It does not handle the backend API contract, the certificate management infrastructure, the latency architecture of your telematics gateway, or the integration surface for the national V2X exchange.

The second common mistake is designing for the vehicles in production today. AIS-230 mandates compliance for vehicles manufactured from October 2028. That means any model entering development or homologation now must be designed for V2X from the ground up. Model cycles in India typically run three to five years. The OEMs that start architecture planning now will be in production with compliant platforms. The ones that start in late 2027 will be requesting homologation extensions.

The third mistake is siloing this work inside the ECU team. V2X touches the OBU firmware, the telematics gateway, the ADAS stack, the OTA pipeline, the PKI infrastructure, and eventually the national exchange integration. It requires a cross-functional API contract definition that most OEM software teams have not produced before.

What This Means for Automotive Leaders

If you are a CTO, VP Engineering, or Head of Software at an OEM, Tier-1 supplier, or mobility platform operating in India, the practical steps for this quarter are:

Assess your telematics gateway architecture against real-time event stream requirements. If it was designed for diagnostics polling, document the gap now and scope the rebuild.

Confirm C-V2X chipset availability with your OBU vendor. Several Tier-1 suppliers are still delivering legacy DSRC-based OBUs. AIS-230 names C-V2X. Substitution is not currently permitted.

Map your PKI dependencies. IEEE 1609.2 certificate management requires a vehicle identity infrastructure that most OEM backend teams do not currently operate. Early engagement with established automotive PKI providers reduces later risk.

Assign an API owner for V2X. Not a hardware owner. Not a firmware owner. Someone who owns the API contracts between the OBU, your telematics gateway, and the downstream application layer. That role does not exist at most Indian OEMs today.

You do not need to have a production-ready V2X stack this quarter. You need to have a credible architecture plan and a clear understanding of your CVACS score. Both of those are achievable in 30 days.

More Blog: Multi-Agent AI in Indian 3PL: Powerful Freight Visibility Before Agent Automation