Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Model S REST API

This site may earn commission on affiliate links.
#2,321
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:
Code: 
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:
Code: 
StreamingServerEndpoints={LOCATION_STREAMING:"streaming/",AUTOPARK_SUMMON:"connect/"}

I can connect to the streaming endpoint and get a `hello` response back:
Code: 
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?
 
  • Like
Reactions: apacheguy
#2,322
josebet1 said:
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:
Code: 
StreamingServerEndpoints={LOCATION_STREAMING:"streaming/",AUTOPARK_SUMMON:"connect/"}

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

Code: 
{"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
Click to expand...

In the response you get from https://owner-api.teslamotors.com/api/1/vehicles
Do you have values for these?
Code: 
    "backseat_token" = "<null>";
    "backseat_token_updated_at" = "<null>";
 
#2,323
To test the websocket service, you can use this curl command :
Code: 
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 :
Code: 
{"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.
 
  • Informative
Reactions: scottf200
#2,325
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.
 
#2,326
Dazboj said:
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:
Code: 
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:
Code: 
StreamingServerEndpoints={LOCATION_STREAMING:"streaming/",AUTOPARK_SUMMON:"connect/"}

I can connect to the streaming endpoint and get a `hello` response back:
Code: 
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?
Click to expand...

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

Code: 
{'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
 
  • Like
Reactions: SG57, tornado and apacheguy
#2,327
josebet1 said:
Yes! After connecting to the websocket, it seems from the code that you need to send a subscribe request formatted like this:

Code: 
{'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
Click to expand...

Yes I actually managed to figure this out myself in the end.
It works fine for me. Model S 2018.21.9
 
#2,328
dpskipper said:
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
Click to expand...
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

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:
Code: 
{
    "speed_limit_mode": {
        "active":true,
        "pin_code_set":true,
        "current_limit_mph":80,
        "min_limit_mph":50,
        "max_limit_mph":90
    },
    ...
}

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:
Code: 
{
    "pin":"1234"
}

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:

Code: 
{
    "limit_mph":75
}
 
Last edited:
#2,329
SG57 said:
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

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:
Code: 
{
    "speed_limit_mode": {
        "active":true,
        "pin_code_set":true,
        "current_limit_mph":80,
        "min_limit_mph":50,
        "max_limit_mph":90
    },
    ...
}

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:
Code: 
{
    "pin":"1234"
}

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:

Code: 
{
    "limit_mph":75
}
Click to expand...

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.
 
#2,330
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
}
 
#2,335
luckyj said:
Little confused on that one - what's the endpoint? Is it api/1/vehicles/{id}/command/speed_limit_set_limit ?
Click to expand...
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.
 
Last edited:
#2,336
@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
 
#2,337
SG57 said:
@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
Click to expand...

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.
 
  • Love
Reactions: SG57
#2,338
@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...
 
Last edited:
#2,339
SG57 said:
@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...
Click to expand...

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.
 
  • Like
Reactions: SG57
#2,340
@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....
 
You must log in or register to reply here.

Similar threads

Struja
My Taycan vs. My Model S
Replies
46
Views
5K
Canada
SMLBound
SMLBound
Tesery
Aftermarket Instrument Cluster Fix Tesla Model 3 & Y
Replies
0
Views
1K
Model 3: Interior & Exterior
Tesery
Tesery
U
2017 Model S vs 2020 Model 3
Replies
5
Views
4K
Model S
Darmie
Darmie
K
  • Article
1 Year Used Tesla Model 3 Review
Replies
6
Views
612
Model 3
KerrySkates
K
Tesery
Vendor A Must-Have Guide for Tesla Model 3 Highland Owners: Tips for Efficiently Selecting Accessories
Replies
1
Views
751
Model 3
Tesery
Tesery
Top
Back
Blog
New
Forum list
Marketplace
Menu