Hello,
We are developing a third-party app ("Voice Car Control", client_id 66018e33-07c1-4e0a-9d00-941084a89dda, EU region — fleet-api.prd.eu.vn.cloud.tesla.com) using the Vehicle Command Protocol via the Fleet API signed_command endpoint.
Vehicle: 2025 Model Y, VIN XP7YGCFS0SB634680, vehicle id 929499398078259. The virtual key is paired (fleet_status → key_paired_vins includes this VIN). Granted scopes: openid offline_access vehicle_device_data vehicle_cmds vehicle_charging_cmds.
What works (verified end-to-end):
signed_command → DOMAIN_VEHICLE_SECURITY (2): session handshake succeeds and HMAC-personalized commands physically execute (lock/unlock confirmed).
wake_up, vehicle list state, vehicle_data — all normal.
What consistently fails:
ANY RoutableMessage to DOMAIN_INFOTAINMENT (3) — including an unauthenticated session_info_request — always returns HTTP 408 {"error":"vehicle is offline"}.
This happens while the vehicle reports state "online", with an occupant inside, screen on, and even while driving.
Retried per official SDK semantics: wake_up then polling every 10 seconds for 60 seconds — no change.
Tried RoutableMessage flags values 0, 1, 2, 3 (FLAG_USER_COMMAND / FLAG_ENCRYPT_RESPONSE) — identical 408 result.
The messages are byte-identical to the working VCSEC handshake except to_destination.domain = 3.
Remedies already attempted: infotainment reboot (scroll-wheel), full vehicle Power Off (3+ minutes), virtual key removal and re-pairing. No change over multiple days.
Sample failed request txids (all 2026-07-02, timezone GMT+3):
73cc10c0b50faf6359330989a673f7ee
0baaeb6719bb0dc82135da19882b0c39
b4b041acea5ca82b9324f1127c518615
For contrast, REST command endpoints correctly return 403 "Tesla Vehicle Command Protocol required", as expected.
Could you check on your side why the command router cannot reach this vehicle's infotainment domain? It looks like a vehicle-side registration/routing issue between the vehicle's infotainment command service and the mothership, specific to this VIN.
Thank you!
Hello,
We are developing a third-party app ("Voice Car Control", client_id 66018e33-07c1-4e0a-9d00-941084a89dda, EU region — fleet-api.prd.eu.vn.cloud.tesla.com) using the Vehicle Command Protocol via the Fleet API signed_command endpoint.
Vehicle: 2025 Model Y, VIN XP7YGCFS0SB634680, vehicle id 929499398078259. The virtual key is paired (fleet_status → key_paired_vins includes this VIN). Granted scopes: openid offline_access vehicle_device_data vehicle_cmds vehicle_charging_cmds.
What works (verified end-to-end):
signed_command → DOMAIN_VEHICLE_SECURITY (2): session handshake succeeds and HMAC-personalized commands physically execute (lock/unlock confirmed).
wake_up, vehicle list state, vehicle_data — all normal.
What consistently fails:
ANY RoutableMessage to DOMAIN_INFOTAINMENT (3) — including an unauthenticated session_info_request — always returns HTTP 408 {"error":"vehicle is offline"}.
This happens while the vehicle reports state "online", with an occupant inside, screen on, and even while driving.
Retried per official SDK semantics: wake_up then polling every 10 seconds for 60 seconds — no change.
Tried RoutableMessage flags values 0, 1, 2, 3 (FLAG_USER_COMMAND / FLAG_ENCRYPT_RESPONSE) — identical 408 result.
The messages are byte-identical to the working VCSEC handshake except to_destination.domain = 3.
Remedies already attempted: infotainment reboot (scroll-wheel), full vehicle Power Off (3+ minutes), virtual key removal and re-pairing. No change over multiple days.
Sample failed request txids (all 2026-07-02, timezone GMT+3):
73cc10c0b50faf6359330989a673f7ee
0baaeb6719bb0dc82135da19882b0c39
b4b041acea5ca82b9324f1127c518615
For contrast, REST command endpoints correctly return 403 "Tesla Vehicle Command Protocol required", as expected.
Could you check on your side why the command router cannot reach this vehicle's infotainment domain? It looks like a vehicle-side registration/routing issue between the vehicle's infotainment command service and the mothership, specific to this VIN.
Thank you!