Model S REST API

[Dazboj]

I've been looking into the new streaming server endpoint.
Firstly, it looks like some(all?) model 3 with recent software can no longer connect to:

https://streaming.vn.teslamotors.com/stream/$VEHICLE_ID/?values=speed,odometer,soc,elevation,est_heading,est_lat,est_lng,power,shift_state

What's interesting however is a model S running the exact same software as me (2018.21.9) also cannot connect to the old streaming endpoint, however I can to my model S on 2018.21.9 perfectly fine!
I have a feeling this is slowly being rolled out.

Looking through the latest Android app binary, we can see they have a new streaming endpoint as mentioned in a post above:

StreamingServerEndpoints={LOCATION_STREAMING:"streaming/",AUTOPARK_SUMMON:"connect/"}

I can connect to the streaming endpoint and get a `hello` response back:

wsta -v -I wss://streaming.vn.teslamotors.com/streaming/
{"msg_type":"control:hello","connection_timeout":0}

Looking through the Android code, this is expected.

The interesting thing with this endpoint is you get a hello response back regardless of any authentication. Simply opening a web socket to is enough.

I'm starting to hit roadblocks in the app now as it's heavily obfuscated and I can't proxy the web socket.

My initial thought is that we need to send an authentication request once the socket is open, but this is as far as I have got so far.
I know it sends a timestamp as a ping, but I can't figure out the full JSON payload to send.

Has anyone else had a chance to look into this?

 

[Dazboj]

Can't get the streaming api to work either on Model 3 (2018.21.9 75bdbc11)

Looking through the APK, I found a "new" streaming endpoint:

StreamingServerEndpoints={LOCATION_STREAMING:"streaming/",AUTOPARK_SUMMON:"connect/"}

but I am unable to connect, server seems to not be able to connect to the car.

{"msg_type":"data:error","tag":"${vehicle_id}","value":"disconnected","error_type":"vehicle_disconnected"}

If anyone wants to try the new endpoint on their Model S or X I can send some sample code over

In the response you get from https://owner-api.teslamotors.com/api/1/vehicles
Do you have values for these?

    "backseat_token" = "<null>";
    "backseat_token_updated_at" = "<null>";

 

[mochouinard]

To test the websocket service, you can use this curl command :

curl --user 'USERNAME:TOKEN' -i -N  --header "Sec-WebSocket-Key: SGVsbG8sIHevcmxkIQ==" -H "Sec-WebSocket-Version: 13" -H "Connection: Upgrade" -H "Upgrade: websocket" -H "Host: streaming.vn.teslamotors.com" -H "Origin: https://streaming.vn.teslamotors.com" https://streaming.vn.teslamotors.com/connect/VEHICLE_ID

Change the USERNAME, TOKEN and VEHICLE_ID to match your info.
Note that you ONLY get this information now at very low frequency :

{"latitude":45.377188,"longitude":-73.60919,"msg_type":"vehicle_data:location"}

It seem to have happen to model 3 only at first, and it seem to be rolling out to model S and X as well now !

I hope it just an error on tesla part, but I feel that tesla is looking to lower their 3g data usage so the good streaming data day might be over !!! I wish we could have had some headup from Tesla about this, giving time to give a solution or inform user of site like mine, teslalog.com.

 

[josebet1]

In the response you get from https://owner-api.teslamotors.com/api/1/vehicles
Do you have values for these?

    "backseat_token" = "<null>";
    "backseat_token_updated_at" = "<null>";

Nope, null for both. I'm on a Model 3, 2018.21.9

Hopefully 2018.24.1 fixes the non-summon streaming APIs

 

[apacheguy]

I can't imagine that Tesla would restrict the API due to cellular data usage. The JSON formatted responses through the streaming API use very little bandwidth unless someone constantly has a stream open for a vehicle. In this case Tesla could simply limit the number of requests in a certain time frame.

 

[josebet1]

I've been looking into the new streaming server endpoint.
Firstly, it looks like some(all?) model 3 with recent software can no longer connect to:

https://streaming.vn.teslamotors.com/stream/$VEHICLE_ID/?values=speed,odometer,soc,elevation,est_heading,est_lat,est_lng,power,shift_state

What's interesting however is a model S running the exact same software as me (2018.21.9) also cannot connect to the old streaming endpoint, however I can to my model S on 2018.21.9 perfectly fine!
I have a feeling this is slowly being rolled out.

Looking through the latest Android app binary, we can see they have a new streaming endpoint as mentioned in a post above:

StreamingServerEndpoints={LOCATION_STREAMING:"streaming/",AUTOPARK_SUMMON:"connect/"}

I can connect to the streaming endpoint and get a `hello` response back:

wsta -v -I wss://streaming.vn.teslamotors.com/streaming/
{"msg_type":"control:hello","connection_timeout":0}

Looking through the Android code, this is expected.

The interesting thing with this endpoint is you get a hello response back regardless of any authentication. Simply opening a web socket to is enough.

I'm starting to hit roadblocks in the app now as it's heavily obfuscated and I can't proxy the web socket.

My initial thought is that we need to send an authentication request once the socket is open, but this is as far as I have got so far.
I know it sends a timestamp as a ping, but I can't figure out the full JSON payload to send.

Has anyone else had a chance to look into this?

Yes! After connecting to the websocket, it seems from the code that you need to send a subscribe request formatted like this:

{'msg_type': 'data:subscribe', 'tag': '${vehicle_id}', 'token': ${base64(email:token:)}, 'value': ["speed","odometer","soc","elevation","est_heading","est_lat","est_lng","est_corrected_lat","est_corrected_lng","native_latitude","native_longitude","native_heading","native_type","native_location_supported","power","shift_state"].toString()}

As I mentioned in post #2307, the websocket replied with vehicle disconnected. Maybe this new endpoint works in a Model S/X

 

[Dazboj]

Yes! After connecting to the websocket, it seems from the code that you need to send a subscribe request formatted like this:

{'msg_type': 'data:subscribe', 'tag': '${vehicle_id}', 'token': ${base64(email:token:)}, 'value': ["speed","odometer","soc","elevation","est_heading","est_lat","est_lng","est_corrected_lat","est_corrected_lng","native_latitude","native_longitude","native_heading","native_type","native_location_supported","power","shift_state"].toString()}

As I mentioned in post #2307, the websocket replied with vehicle disconnected. Maybe this new endpoint works in a Model S/X

Yes I actually managed to figure this out myself in the end.
It works fine for me. Model S 2018.21.9

 

[SG57]

Anyone got the new firmware that allows the speed limit via app?

I would love to see the endpoint.

Paging @SG57 for his mad skillz

Okay, reverse engineered the official app and figured out the new Speed Limit APIs. Cannot confirm them working on my end as I do not have the latest firmware on my Model S, but these should do the trick.

-

Also, there's a new autopark (summon) state "version", autopark_state_v3, likely for the model 3 summon update.

Also for what it's worth there's a new notifications API, POST api/1/notification_confirmations , that only is used upon receiving a notification whose payload contains a true value for the key delivery_confirmation.

This leads me to believe notifications are now being served that expect confirmation they either arrived or that the end-user needs to confirm, and if not then the notification will be re-sent soon after until confirmation is received.

I can see this being useful for the Supercharger network where the user must confirm and accept that they are now accruing idle fees or if their car alarm went off the notification is forcibly addressed.

-

Speed Limit

Spoiler: Current State

Current State

Endpoint:

• api/1/vehicles/{id}/data_request/vehicle_state

Method: GET

Query:

• {id} is your vehicle "id" ( not your "vehicle_id")

Response Body:

{
    "speed_limit_mode": {
        "active":true,
        "pin_code_set":true,
        "current_limit_mph":80,
        "min_limit_mph":50,
        "max_limit_mph":90
    },
    ...
}

Spoiler: Activate, Deactivate, Clear PIN

Activate, Deactivate, Clear PIN

Endpoint:

• api/1/vehicles/{id}/command/speed_limit_activate
• api/1/vehicles/{id}/command/speed_limit_deactivate
• api/1/vehicles/{id}/command/speed_limit_clear_pin

Method: POST

Query:

• {id} is your vehicle "id" ( not your "vehicle_id")

Request Body:

{
    "pin":"1234"
}

Spoiler: Set Speed Limit

Set Speed Limit

Endpoint:

• api/1/vehicles/{id}/command/speed_limit_set_limit

Method: POST
Query:

• {id} is your vehicle "id" (not your "vehicle_id")

Request Body:

{
    "limit_mph":75
}

 

[Dazboj]

Okay, reverse engineered the official app and figured out the new Speed Limit APIs. Cannot confirm them working on my end as I do not have the latest firmware on my Model S, but these should do the trick.

-

Also for what it's worth there's a new notifications API, POST api/1/notification_confirmations , that only is used upon receiving a notification whose payload contains a true value for the key delivery_confirmation.

This leads me to believe notifications are now being served that expect confirmation they either arrived or that the end-user needs to confirm, and if not then the notification will be re-sent soon after until confirmation is received.

I can see this being useful for the Supercharger network where the user must confirm and accept that they are now accruing idle fees or if their car alarm went off the notification is forcibly addressed.

-

Speed Limit

Spoiler: Current State

Current State

Endpoint:

• api/1/vehicles/{id}/data_request/vehicle_state

Method: GET

Query:

• {id} is your vehicle "id" ( not your "vehicle_id")

Response Body:

{
    "speed_limit_mode": {
        "active":true,
        "pin_code_set":true,
        "current_limit_mph":80,
        "min_limit_mph":50,
        "max_limit_mph":90
    },
    ...
}

Spoiler: Activate, Deactivate, Clear PIN

Activate, Deactivate, Clear PIN

Endpoint:

• api/1/vehicles/{id}/command/speed_limit_activate
• api/1/vehicles/{id}/command/speed_limit_deactivate
• api/1/vehicles/{id}/command/speed_limit_clear_pin

Method: POST

Query:

• {id} is your vehicle "id" ( not your "vehicle_id")

Request Body:

{
    "pin":"1234"
}

Spoiler: Set Speed Limit

Set Speed Limit

Endpoint:

• api/1/vehicles/{id}/command/speed[cur]limit[/cur]set_limit
  Method: POST

Query:

• {id} is your vehicle "id" ( [cur]not[/cur] your "vehicle_id")

Request Body:

{
    "limit_mph":75
}

I got the car update today and had a play with this also. I can confirm that there is server side validation for the speed limit and it’s not possible to set one lower than 50.

 

[luckyj]

Got 2018.24.1 today, coming from 2018.21.9.

Noticed that autopark_state was removed from vehicle state. Now there's only autopark_state_v2.

Also noticed the new speed_limit_mode under vehicle state, as SG57 mentioned:

"speed_limit_mode": {
"active": false,
"current_limit_mph": 85,
"max_limit_mph": 90,
"min_limit_mph": 50,
"pin_code_set": false
}

 

[wayner]

I got the car update today and had a play with this also. I can confirm that there is server side validation for the speed limit and it’s not possible to set one lower than 50.

Is this 50 km/h or 50 mi/h?

 

[Dazboj]

Is this 50 km/h or 50 mi/h?

I’m not sure. Mines set to mph and it wouldn’t accept a value lower than 50

 

[luckyj]

Set Speed Limit

Endpoint:

• api/1/vehicles/{id}/command/speed[cur]limit[/cur]set_limit
  Method: POST

Query:

• {id} is your vehicle "id" ( [cur]not[/cur] your "vehicle_id")

Request Body:

{
    "limit_mph":75
}

Little confused on that one - what's the endpoint? Is it api/1/vehicles/{id}/command/speed_limit_set_limit ?

 

[Dr. McKay]

speed_limit_set_limit

 

[SG57]

Little confused on that one - what's the endpoint? Is it api/1/vehicles/{id}/command/speed_limit_set_limit ?

Ah my bad, fixed it. Conversion from markdown to BB code sucked apparently.

@wayner , 50 MPH to 90 MPH is the current standard Tesla manages server-side. In kilometers it's 80 KPH to 145 KPH, but the APIs require it in MPH (limit_mph), luckily the conversion rounds off nicely between the two limits.

 

[SG57]

@Dazboj & @luckyj , seeing as how you both have access to test the speed limit mode would you mind verifying the functional behavior of the speed limit APIs?

I'm asking because reverse engineering the official app stops

The set limit API is straight forward to infer from looking at the official app's code, expects a "limit_mph" property in the request body, it does not require a pin, and only works if the speed limit mode is not active.

The activate, deactivate, and clear pin APIs accept a pin in the request body, however I can't deduce if this is always required in the case the "pin_code_set" is true. My best guess is it doesn't require a pin if a pin code is set and you're activating the speed limit mode. It would only require a pin if one is not set. Deactivating the mode I would guess would require a PIN, but valet mode doesn't require a pin to turn it off and on from the app so I can't be sure without testing in person.

Lastly, the clear PIN API only works when the speed limit mode is inactive, but it also accepts a PIN, is this required?

I'd appreciate your help figuring out this behavior, and honestly in a perfect world one of you would trust me, a total stranger, with your authorization token for 15 minutes for me to figure the behavior out for myself :3 You would be free to revoke your auth token afterwards just to be sure, but this really is the last resort for me.

Worst case I wait until I can get the firmware update! :3

 

[Dazboj]

@Dazboj & @luckyj , seeing as how you both have access to test the speed limit mode would you mind verifying the functional behavior of the speed limit APIs?

I'm asking because reverse engineering the official app stops

The set limit API is straight forward to infer from looking at the official app's code, expects a "limit_mph" property in the request body, it does not require a pin, and only works if the speed limit mode is not active.

The activate, deactivate, and clear pin APIs accept a pin in the request body, however I can't deduce if this is always required in the case the "pin_code_set" is true. My best guess is it doesn't require a pin if a pin code is set and you're activating the speed limit mode. It would only require a pin if one is not set. Deactivating the mode I would guess would require a PIN, but valet mode doesn't require a pin to turn it off and on from the app so I can't be sure without testing in person.

Lastly, the clear PIN API only works when the speed limit mode is inactive, but it also accepts a PIN, is this required?

I'd appreciate your help figuring out this behavior, and honestly in a perfect world one of you would trust me, a total stranger, with your authorization token for 15 minutes for me to figure the behavior out for myself :3 You would be free to revoke your auth token afterwards just to be sure, but this really is the last resort for me.

Worst case I wait until I can get the firmware update! :3

You are right, you set the speed first only while it’s not active.
Pin is required with all 3 of the other requests.
When you enable the speed limit mode, the app asks for your pin. If one is already set, it must match. If one isn’t set, any will do.
Disabling requires the pin.
Clearing is only available when disabled.

 

[SG57]

@Dazboj , excellent thank you! Just to be concise, the clear pin API requires a pin? I ask because what if you forget your pin, is there really no way to clear it? Does the new firmware add a way to clear the PIN in the car? I guess valet mode has this problem as well...

 

[Dazboj]

@Dazboj , excellent thank you! Just to be concise, the clear pin API requires a pin? I ask because what if you forget your pin, is there really no way to clear it? Does the new firmware add a way to clear the PIN in the car? I guess valet mode has this problem as well...

Yes you send the pin to the clear pin endpoint. Valet mode doesn't need this which seems odd.
I haven't tried to clear the pin in the car, but you can set the pin in the car if it's not already been set in the app.

I'm sure I saw a prompt or link to reset the pin using my Tesla login details, but I can't seem to find it now. Maybe it's in the car.

 

[insaneoctane]

@L-P-G or anyone else,
Do you know if frequent checks to
https://owner-api.teslamotors.com/api/1/vehicles/ run any risk of waking or keeping the car awake? I am assuming that the "vehicles" endpoint is to the Tesla server and not to the car. ..

I'm looking to be notified fairly quickly once the car gets plugged in but I don't want to wake up or prevent sleeping so I figured if it's not plugged in and asleep I would see the car awake from the server status before I would start to ask the car....