Model S REST API

[SG57]

@bharned3 , the apps have local resources for every vehicle render broken out into composite layers for backdrop, vehicle body, vehicle body paint, wheels, etc. This is done for different angles of the vehicle and for each configuration for right-hand drive and for each individual door, charge port, trunk, frunk, hood, interior for each model S, X, and 3 at this time. To color your vehicle they run a color filter over the paint mask for your specific paint.

Attached are a few samples:

 

[bharned3]

g'day mate. Most likley either the app has a bunch of images stored in it with each possible color/wheel/sunroof/spoiler/nosecone combo.

The actual backend system that generates the images is called the tesla compositor...

All ya have to do is go to the tesla studio, play around with a config you like, and then open the image in a new tab... The URL that comes up has a bunch of parameters in it, those 'codes' are what tells the compositing system what the car looks like.

For a jump-start on how this system works, consult this thread: Tesla website compositor

cheers!

Awesome thanks I will heck this out

 

[bharned3]

@bharned3 , the apps have local resources for every vehicle render broken out into composite layers for backdrop, vehicle body, vehicle body paint, wheels, etc. This is done for different angles of the vehicle and for each configuration for right-hand drive and for each individual door, charge port, trunk, frunk, hood, interior for each model S, X, and 3 at this time. To color your vehicle they run a color filter over the paint mask for your specific paint.

Attached are a few samples:

View attachment 268020 View attachment 268021 View attachment 268022 View attachment 268023

Thanks.. had no clue it was done like that

 

[SG57]

Looking at a few API results from a Model 3, I'm seeing some interesting changes.

For starters, there is no trim on the vehicle so the trim_badging property is empty. Sad, I was really hoping to see a hidden battery pack size or something.

A big change I'm seeing across all the Model 3s I've looked at is that the estimated range is always returning 0 (even using streaming APIs), and that both the rated range and ideal range are returning the exact same values. Also, I'm seeing the last charge data for the rated and ideal energies added ALSO returning the same exact value. I suspect for Model 3's that Tesla has decided to do away with the concept of rated, ideal, and estimated ranges in favor of 1 single range?? 313 miles is the max range of these Model 3s as per the values I'm seeing, so this is probably rated.

I notice the plg property is null despite the can_actuate_trunks property being true, so I don't think that plg stands for Power Lift Gate as suspected.

I notice a new conn_charge_cable property in the charge state, I suspect Tesla is now reporting on what brand of charge cable is being used. So far the only non-null value I've seen here is SAE, no idea what that means but the car is plugged into a standard 120V 5A outlet.

I haven't seen a full list of option codes posted for Model 3 before, so here is a 300 mile range Model 3:

AD15,MDL3,PBSB,RENA,BT37,ID3W,RF3G,S3PB,DRLH,DV2W,W39B,APF0,COUS,BC3B,CH07,PC30,FC3P,FG31,GLFR,HL31,HM31,IL31,LTPB,MR31,FM3B,RS3H,SA3P,STCP,SC04,SU3C,T3CA,TW00,TM00,UT3P,WR00,AU3P,APH3,AF00,ZCST,MI00,CDM0

There are some interesting things to note in this list.

Notice the BT37 option code, these BT option codes typically indicate battery size, such as BT85 for the 85 kwh pack.

Also worth noting is the RF3G option code, curious what this means as this is for the roof. Known option codes for other models have RFPO or RFP2 for sun roofs, or RFFG for glass roof, or RFBC for body color, or RFPX for the model X roof.

 

[lunitiks]

I haven't seen a full list of option codes posted for Model 3 before, so here is a 300 mile range Model 3:

Awesome, thank you.

I sorted your data alphabetically, and ran them against known option codes (categories and values) from MS/MX. Notice that some categories are completely new for Model 3. The "-" mark means I don't know.

CODE	CATEGORY	VALUE
AD15	Adapter:	-
AF00	Filter:	-
APF0	Autopilot:	[No Autopilot]
APH3	Autopilot_Hardware:	[Autopilot HW 2.5]
AU3P	Audio:	-
BC3B	Calipers:	-
BT37	Battery:	-
CDM0	Adapter:	[No CHAdeMO Charging Adaptor]
CH07	Charger:	-
COUS	Country:	[US]
DRLH	Drive_Side:	[Left Hand Drive]
DV2W	Motor:	[Two Wheel Drive]
FC3P	-	-
FG31	Fog_Lamp:	-
FM3B	Firmware_Limitation / Firmware_Performance:	-
GLFR	Assemble:	[Fremont]
HL31	-	-
HM31	-	-
ID3W	Decor:	-
IL31	-	-
LTPB	Lower_Trim / "Not_Used" / "Int_Type_Flag":	-
MDL3	Model:	[Model 3]
MI00	MFG_Intro:	-
MR31	-	-
PBSB	Paint:	[Solid Black]
PC30	-	-
RENA	Region:	[North America]
RF3G	Roof:	-
RS3H	-	-
S3PB	Seat_Package:	-
SA3P	-	-
SC04	Supercharger:	-
STCP	Steering_Wheel / "Not_Used":	-
SU3C	Suspension:	-
T3CA	-	-
TM00	Trim:	[General Production Trim]
TW00	-	-
UT3P	Upper_Trim:	-
W39B	Wheels:	-
WR00	Wrap:	-
ZCST	Order_Type:	-

Notice the BT37 option code, these BT option codes typically indicate battery size, such as BT85 for the 85 kwh pack.

Also worth noting is the RF3G option code, curious what this means as this is for the roof.

Notice that the number "3" is in many of the option codes. That's probably because it's a Model 3, so it's got some special options that MS/MX don't have.

 

[lunitiks]

"BT37" is obviously a code for battery type/size, like you said. Why they put "37" we can only speculate. Could it be a weird / L33T way of saying "Model 3 Long Range"? I.e. the "7" is an upside down "L"?
(So when the short range batt. comes, could we expect something like "BT35"?)

 

[SG57]

Ahhh that's a useful hint @lunitiks . So the RF3G option code could mean glass roof for the Model 3. Same with battery, BT37, where the 7 could mean 70 kwh battery pack, or it could have no relationship to the kwh size of the pack and more of a long range battery pack arbitrary "size" number with 7 being long.

 

[dpskipper]

I notice the plg property is null despite the can_actuate_trunks property being true, so I don't think that plg stands for Power Lift Gate as suspected.

@SG57 here is the dump of my vehicle:

"vehicle_config": {
"can_actuate_trunks": false,
"car_special_type": "base",
"car_type": "models2",
"charge_port_type": "EU",
"eu_vehicle": true,
"exterior_color": "White",
"has_ludicrous_mode": false,
"motorized_charge_port": false,
"perf_config": "P3",
"plg": true,
"rear_seat_heaters": 0,
"rear_seat_type": 1,
"rhd": true,
"roof_color": "None",
"seat_type": 1,
"spoiler_type": "None",
"sun_roof_installed": 2,
"third_row_seats": "None",
"timestamp": 1514881497424,
"trim_badging": "75d",
"wheel_type": "Charcoal21"

The car in question is a 2016 MS with (at the time) the 'Tech Package' so power liftgate is an option I have.
can_actuate_trunks is false as expected, but this gives more credit to plg being power lift gate....

 

[Xtek]

I notice the plg property is null despite the can_actuate_trunks property being true, so I don't think that plg stands for Power Lift Gate as suspected.

It makes perfect sense for plg to be null and can_actuate_trunks to be true. Actuate doesn't inherently mean open/close it means to operate. It's saying you can actuate the frunk/trunk releases not "you can open and close it fully".

 

[bmah]

The car in question is a 2016 MS with (at the time) the 'Tech Package' so power liftgate is an option I have.

Sorry to distract from the discussion at hand but are you sure about that? IIRC the Tech Package went away around April 2015 (right after I configured my car in March 2015). Maybe you mean the Premium Upgrade Package? (or whatever package at the time that the word "Premium" in it)

Bruce.

 

[dpskipper]

Sorry to distract from the discussion at hand but are you sure about that? IIRC the Tech Package went away around April 2015 (right after I configured my car in March 2015). Maybe you mean the Premium Upgrade Package? (or whatever package at the time that the word "Premium" in it)

Bruce.

I don't remember exactly bruce. But I ordered my car a long time before it was actually built. I ordered when the classic noses where around, and several months later my car was built, and I picked up extra features like the refreshed front nose.

I remember, I picked the Tech Package and premium upgrade package. So i've got the interior lighting stuff, and hepa filter etc...

 

[timdorr]

@wayner and @scottf200 , I have no problem sharing technical details, but I do side on safety when it comes to sharing IDs, keys, and such.

There are a number of APIs not documented, both old and new, some I know how to use, some I don't. It would take me some time to document but here are 2 quick ones not documented elsewhere:

The documentation is entirely open source. Could you submit a PR to add those? I'd love to get it included.

 

[Xtek]

The documentation is entirely open source. Could you submit a PR to add those? I'd love to get it included.

I’d also like to hear of these. After tearing apart the Android and IOS apps the only ones I’ve found missing is actuate trunks and the new summon API. Also revoke token.

 

[SG57]

I’d also like to hear of these. After tearing apart the Android and IOS apps the only ones I’ve found missing is actuate trunks and the new summon API. Also revoke token.

I've detailed the actuate trunk and revoke token APIs in this thread here:
Model S REST API

I've detailed the push notification APIs few weeks ago in this thread here:
Model S REST API

The APIs I haven't detailed that are lacking documentation I could create are the streaming telemetry API, summon API, calendar sync API, referral API, and command auth token API (for clarity, this one is currently only used for sending a remote start command without knowing the user's password).

There are some APIs I know exist that aren't worth documenting, such as official app diagnostics and logging info.

The APIs I know exist that I haven't fully reverse engineered yet are the Powerwall API and the Model 3 bluetooth smart device API where the latter is a combination of web service API and bluetooth device API. It is particularly difficult reverse engineering these APIs when not having a Powerwall or a Model 3 to actually test these on and I'm left with crawling the official app source or internet forums for clues. It'd be awesome if others could help out here, even if only by offering their vehicle up for trustworthy testing either remotely or locally.

End of the day I just don't have time to document APIs, reverse engineer APIs, develop and manage an app with a large user base, work a full-time job, and have some sort of social life.

 

[Xtek]

I've detailed the actuate trunk and revoke token APIs in this thread here:
Model S REST API

I've detailed the push notification APIs few weeks ago in this thread here:
Model S REST API

The APIs I haven't detailed that are lacking documentation I could create are the streaming telemetry API, summon API, calendar sync API, referral API, and command auth token API (for clarity, this one is currently only used for sending a remote start command without knowing the user's password).

There are some APIs I know exist that aren't worth documenting, such as official app diagnostics and logging info.

The APIs I know exist that I haven't fully reverse engineered yet are the Powerwall API and the Model 3 bluetooth smart device API where the latter is a combination of web service API and bluetooth device API. It is particularly difficult reverse engineering these APIs when not having a Powerwall or a Model 3 to actually test these on and I'm left with crawling the official app source or internet forums for clues. It'd be awesome if others could help out here, even if only by offering their vehicle up for trustworthy testing either remotely or locally.

End of the day I just don't have time to document APIs, reverse engineer APIs, develop and manage an app with a large user base, work a full-time job, and have some sort of social life.

There's also products and keys but they don't have much value either. I thought the streaming telemetry was known.

 

[SG57]

There's also products and keys but they don't have much value either. I thought the streaming telemetry was known.

The telemetry and summon APIs are known, but they aren't documented anywhere similar to the likes of Timdorr's unofficial documentation on apiary.

Right now to use telemetry or summon for yourself you will be scouring the forums looking piecing it together yourself, which sucks.

 

[Xtek]

The telemetry and summon APIs are known, but they aren't documented anywhere similar to the likes of Timdorr's unofficial documentation on apiary.

Right now to use telemetry or summon for yourself you will be scouring the forums looking piecing it together yourself, which sucks.

Ah yes, good point.

Also, if you want to see how diagnostics works shake your phone, I have the request captured. Not super interesting.

EDIT: Shake your phone with the app open, it's not a shake weight

 

[Desmondo]

Hi all....first post here

I've been using this thread to help me out with my own home automation system to send commands and receive data from the car.

I'm trying to unlock the charge port but can't get it to work. When I tested for the command it looks like it's using the open charge port command but I'm not sure if that's correct?

 

[markmobi]

I wonder if anyone has any thoughts on this.

I'm calling /vehicles/xxxxxxxxxxxxxxxxxxx/command/set_valet_mode and the response is a status code of 200 OK. And the JSON response is: {"response": {"reason": "invalid password", "result": false}}

Does anyone know what this might be? Could it be something to do with the valet mode PIN not being set? Has anyone else had a "invalid password" response before?

Cheers!

 

[Desmondo]

You need to set a password otherwise you get that result, I just tested it on my system.

The password needs to be passed like this.... { "on":true , "password":"1234" } but only the first time.
Once a password has been set you don't need to send it every time.