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.
Hi guys ,
I'm a bit late to the party.
I was wondering - with all the hard work being done here. Would it be possible for devs that want to dive in but DO NOT own a Tesla or have access to one, to create some sort of sandbox environment.

Obviously I'm not talking just creating user credentials on teslamotors.com/mytesla - cause anyone can do that - but to be able to tap into the API we would need to get a valid response returning a (dummy?) vehicle id and all the other response data that the api would return.

Thanks.
 
Hi guys ,
I'm a bit late to the party.
I was wondering - with all the hard work being done here. Would it be possible for devs that want to dive in but DO NOT own a Tesla or have access to one, to create some sort of sandbox environment.

Obviously I'm not talking just creating user credentials on teslamotors.com/mytesla - cause anyone can do that - but to be able to tap into the API we would need to get a valid response returning a (dummy?) vehicle id and all the other response data that the api would return.

Thanks.
Are you planning on getting the vehicle and just want to get a head start on the software to burn some time while you wait? Or did you have an interest in writing some apps for one of phone/tablet/laptop/desktop stores? Or something else?

I wrote a quick puller last night in C#. It took me a few hours (TV is distracting ;)) to get it reliably pulling (with the re-auth, etc.) and has been running for about 22 hours steady now. It's pretty straightforward.
 
Are you planning on getting the vehicle and just want to get a head start on the software to burn some time while you wait? Or did you have an interest in writing some apps for one of phone/tablet/laptop/desktop stores? Or something else?

I wrote a quick puller last night in C#. It took me a few hours (TV is distracting ;)) to get it reliably pulling (with the re-auth, etc.) and has been running for about 22 hours steady now. It's pretty straightforward.

I currently have no personal purchase planned, but there is a possibility that I will be working with Teslas in the near future.
Just trying to get a grasp on things so I can prepare and get an overview of what's on the table , but it's hard to see in the dark (not having valid sandbox dummy data coming back) :/
 
replying to my own question more or less:
on Tesla Model S REST API—by apiary.io , on the right of the page is a link to do a sign-in ... after signin, you get a mockurl where you can play around.
it seems to hold some default values.
eg. I got this out of a clean call to the /vehicles endpoint (just sending along my teslamotors.com username and pass - again - I don't have a Tesla on order ... so this vehicle ID of 321 is just the default value in the mock REST api I presume)
[{
"color": null,
"display_name": null,
"id": 321,
"option_codes": "MS01,RENA,TM00,DRLH,PF00,BT85,PBCW,RFPO,WT19,IBMB,IDPB,TR00,SU01,SC01,TP01,AU01,CH00,HP00,PA00,PS00,AD02,X020,X025,X001,X003,X007,X011,X013",
"user_id": 123,
"vehicle_id": 1234567890,
"vin": "5YJSA1CN5CFP01657",
"tokens": ["x", "x"],
"state": "online"
}]
 
After running steady for over a week, my REST app started reported back that the "tokens" block is empty from the login basically at the stroke of midnight on 05/24 (and is still having the same issue). Anybody else seeing this?

Update 1:
Clarification: (After updating my app...) It seems the streaming API is broken, but the rest is working.

Update 2:
Apparently there is a starting "wake_up" required. I thought this was only necessary after discovering your token is expired, not for generating the first token. After another update to my app, it seems to be back in business. Apparently my previous run had been seeded by some debugging that benefitted from an additional wake_up from the debugging.
 
Last edited:
Speaking of the streaming API. I discovered two new values that I was unaware of ("range" and "est_range"). One was from Cliff Hannel's teslatrackerapp and the other was an educated guess.

The full list that I know of is:

speed, odometer, soc, elevation, heading, est_heading, est_lat, est_lng, power, shift_state, range, est_range
 
Speaking of the streaming API. I discovered two new values that I was unaware of ("range" and "est_range"). One was from Cliff Hannel's teslatrackerapp and the other was an educated guess.

The full list that I know of is:

speed, odometer, soc, elevation, heading, est_heading, est_lat, est_lng, power, shift_state, range, est_range

Has anyone created documentation for the streaming API? It doesn't look like it's in the docs linked to in the first post.
 
Thanks for the heads up on est_range. Added it to my logging.

- - - Updated - - -

Has anyone created documentation for the streaming API? It doesn't look like it's in the docs linked to in the first post.
I found this helpful:
https://docs.google.com/document/d/1ctuUKgEwi9JlQCjLX40Yx7n1pYKRnRsO6I7RzrPd3Sk/edit?pli=1

It was referenced in one of the comments off of the timdorr pages linked in the first post of this thread.

- - - Updated - - -

I've never range charged my P85.
range, est_range
For the week's worth of data that I've logged so far, my max "range" was 249.
For the few minutes worth of data I've logged so far, it appears that "est_range" is something akin to the Projected Range that we used to have:
  • range,est_range
  • 199,153
  • 200,153
  • 200,154
  • 200,154
  • 201,154
  • 200,154
  • 201,154
  • 201,155
  • 202,155
  • 203,155
  • 203,156
    ...
  • 243,184

My "last 15 miles" consumption was 465 Wh/mi according to the in-car UI. Also, I have my UI set to display Rated (i.e. not Ideal).

Assuming all those numbers play out like I expect and I didn't mess up in Excel that points to a Rated value of ~357 Wh/mi. which seems quite a bit off.

Does this match what you're seeing, Hans?

- - - Updated - - -

Update:
The average for the last 30 mi was 400 Wh/mi. Using that number, the Rated Wh/mi is in the 307 range in the middle of the pack and 304 at the 93-94% charge state. That starts to make sense. I thought the old projected was the last 15 miles, but maybe I'm misremembering and it was the last 30 miles. The stray from 304 (i.e. 307) might be explainable by the integer rounding of the range and est_range data.
 
Last edited:
The 1.31.11-style version is in vehicle_state. Note there's a typo in the original apiary docs ("verson")
Thanks for pointing out what I missed. :)

From https://portal.vn.teslamotors.com/vehicles/<id>/command/vehicle_state ...
  • df=false
  • dr=false
  • pf=false
  • pr=false
  • ft=false
  • rt=false
  • car_version=1.31.11
  • locked=true
  • sun_roof_installed=true
  • sun_roof_state=unknown
  • sun_roof_percent_open=0
  • dark_rims=false
  • wheel_type=Silver21
  • has_spoiler=false
  • roof_color=None
  • perf_config=Sport

Interesting: That might also explain why my About and other renderings of my car don't show my spoiler properly. I'll have to add that to my servicing list.
 
Thanks for pointing out what I missed. :)
[...]
Interesting: That might also explain why my About and other renderings of my car don't show my spoiler properly. I'll have to add that to my servicing list.

That is one service item that can be fixed with a phone call. They can update their database while you are still on the line and verify that the new info is displayed correctly in the car
 
Thanks for pointing out what I missed. :)

From https://portal.vn.teslamotors.com/vehicles/<id>/command/vehicle_state ...
  • df=false
  • dr=false
  • pf=false
  • pr=false
  • ft=false
  • rt=false
  • car_version=1.31.11
  • locked=true
  • sun_roof_installed=true
  • sun_roof_state=unknown
  • sun_roof_percent_open=0
  • dark_rims=false
  • wheel_type=Silver21
  • has_spoiler=false
  • roof_color=None
  • perf_config=Sport

Interesting: That might also explain why my About and other renderings of my car don't show my spoiler properly. I'll have to add that to my servicing list.

Note that 4.5 changes much of the API used. Door open/closed now is an integer instead of boolean. Power liftgate open is '32' instead of '1' or 'true', which confuses the hell out of the app. Should be fixed in the next release of the app, I'm told.

Also, the status_charge fields have also changed, with plenty of additions. I dropped a few notes in the apiary site.
 
Note that 4.5 changes much of the API used. Door open/closed now is an integer instead of boolean. Power liftgate open is '32' instead of '1' or 'true', which confuses the hell out of the app. Should be fixed in the next release of the app, I'm told.

Also, the status_charge fields have also changed, with plenty of additions. I dropped a few notes in the apiary site.
Did the format or parameters of any of the queries change?
 
Did the format or parameters of any of the queries change?

Well, obviously the door ones I mentioned earlier. Here's a dump of the charging values from mine:

onyx:102:~>tesla charge_state
{
"battery_current": -0.6,
"battery_heater_on": false,
"battery_level": 90,
"battery_range": 234.1,
"charge_enable_request": true,
"charge_limit_soc": 90,
"charge_limit_soc_max": 100,
"charge_limit_soc_min": 50,
"charge_limit_soc_std": 90,
"charge_port_door_open": true,
"charge_rate": -1.0,
"charge_starting_range": null,
"charge_starting_soc": null,
"charge_to_max_range": false,
"charger_actual_current": 0,
"charger_pilot_current": 60,
"charger_power": 0,
"charger_voltage": 0,
"charging_state": "Complete",
"est_battery_range": 186.16,
"fast_charger_present": false,
"ideal_battery_range": 269.43,
"max_range_charge_counter": 0,
"not_enough_power_to_heat": false,
"scheduled_charging_pending": false,
"scheduled_charging_start_time": null,
"time_to_full_charge": 0.0,
"user_charge_enable_request": null
}