Model S REST API

[sebas]

@LastGas to login the parameters are a send "x-www-form-urlencoded" which basically is to concatenate all the values in the body as plain text. What I'm using to test the different API calls is Postman. Great tool to work with any api and it can return the request in e.g. cURL or JS code.

This is the cURL command to login. Change your credentials to test it.

curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -H "Accept-Encoding: application/json" -d 'grant_type=password&client_id=e4a9949fcfa04068f59abb5a658f2bac0a3428e4652315490b659d5ab3f35a9e&client_secret=c75f14bbadc8bee3a7594412c31416f8300256d7668ea7e6e7f06727bfb9d220&email=YOUR_EMAIL_HERE&password=YOUR_PASSWORD_HERE' "https://owner-api.teslamotors.com/oauth/token"

This will return a JSON object with the token you will need to add to subsequent requests. The token is added in the Authorization header prefixed with "Bearer ".

 

[LastGas]

@sebas
Thanks. I would never have guessed to put it in the body that way. Your suggestion works in the Model S JSON API page, so I should be able to proceed.

I guess I'll need to sleep on this. I put a protocol trace in my program and it showed (email and password substituted)

POST /oauth/token HTTP/1.0
Content-Type: application/json
Content-Length: 214
Host: owner-api.teslamotors.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: application/x-www-form-urlencoded, identity
User-Agent: Mozilla/3.0 (compatible; Indy Library)


grant_type=password&client_id=e4a9949fcfa04068f59abb5a658f2bac0a3428e4652315490b659d5ab3f35a9e&client_secret=c75f14bbadc8bee3a7594412c31416f8300256d7668ea7e6e7f06727bfb9d220&[email protected]&password=rocket

I got an error 401: Invalid request.

 

[LastGas]

I see the problem, nevermind. I had the headers switched. Code working now! I have an oath token. Yoohoo!

 

[LastGas]

That was a dirty little trick. The API returns an "id" and a "vehicle_id". The documentation says {vehicle_id} is what to use on subsequent calls, but it's really {id}.

Anyhow, I have all the "State and Settings" calls working now. In the morning, we shall try to honk the horn.

 

[sebas]

Any tips on implementation strategies for polling the Tesla API? Does Tesla allow me to continuously poll the different endpoints every minute 24/7 to collect all the data?

 

[dpskipper]

The dev from VisibleTesla tried that. It didn't work too well for him. Tesla contacted him and reminded him we was really hammering the servers. I've also heard rumors that Tesla will throttle/switch off all remote server access on a per account basis if too much traffic is coming from that account.

 

[tliving]

My script detected 4 new fields in the API today:

1) vehicle_state->time stamp
ex: timestamp: 1484278017699

2) charge_state->time stamp
ex: timestamp: 1484278018398

3) charge_state->charge_port_led_color
ex: charge_port_led_color: Blue

4) drive_state->power
ex: power: 0

I'm most excited about the charge_state time stamp and the drive state power. Those could be interesting.

 

[Andyw2100]

My script detected 4 new fields in the API today:

1) vehicle_state->time stamp
ex: timestamp: 1484278017699

2) charge_state->time stamp
ex: timestamp: 1484278018398

3) charge_state->charge_port_led_color
ex: charge_port_led_color: Blue

4) drive_state->power
ex: power: 0

I'm most excited about the charge_state time stamp and the drive state power. Those could be interesting.

Do you think these additions could allow Tesla to work "end-time charge scheduling" into the app?

 

[tliving]

Do you think these additions could allow Tesla to work "end-time charge scheduling" into the app?

I think they could have done that without these. The thing that was really a pain before was that you didn't know when the charge_state was from. Having a timestamp allows you to only look at it when that changes.

 

[Andyw2100]

I think they could have done that without these. The thing that was really a pain before was that you didn't know when the charge_state was from. Having a timestamp allows you to only look at it when that changes.

Thanks for the quick response.

End-time charge scheduling would be a nice addition to the app, but what I am really hoping for (and I'm pretty sure this would definitely need some new API fields) is some sort of battery pre-heating, separate from cabin pre-heating.

 

[wayner]

Do you think these additions could allow Tesla to work "end-time charge scheduling" into the app?

Where would they get the charge rate which is crucial to know how long it will take to charge? Would they use history from charging at a given location? Would they do a pilot charge for a minute or two to test the charge rate?

 

[Andyw2100]

Where would they get the charge rate which is crucial to know how long it will take to charge? Would they use history from charging at a given location? Would they do a pilot charge for a minute or two to test the charge rate?

The answer depends on how sophisticated they want to be, and on how many options they want to give us.

They could use charge history at the location.

They could also allow us input with respect to whether reaching our set charge percentage or not finishing early is more of a priority. So, for example, if I set the priority to not finishing early, if for some reason the charge takes longer than expected, then the charge simply will not have reached my set percentage. On the other hand, if I set my priority as reaching the charge level, then the charge will have to start early enough to make sure it does, and that could mean it finishes early.

Tesla could get even fancier, and let us select a range of acceptable charge rates (32 amps, 56 amps, 72 amps, etc) and could then start at a high rate and adjust up or down as needed, as the charge gets closer to finishing.

There are a lot of ways this could be implemented.

 

[wayner]

I wrote a python script last year where I just hard coded in the charge rate for me which was about 0.33 percentage charge points per minute for my 80A 240V HPWC. I wanted to end charging at 7am which is around my departure and is also when my electric rate goes up by about $0.09/kWh.

 

[sebas]

The dev from VisibleTesla tried that. It didn't work too well for him. Tesla contacted him and reminded him we was really hammering the servers. I've also heard rumors that Tesla will throttle/switch off all remote server access on a per account basis if too much traffic is coming from that account.

Hmm, I can imagine they throttle their API or deny anyone access who's over-using it. How do sites like Teslalog then gather data? The streaming API? I'd like to log charging sessions, distance driven etc. As there is no API to get historical data I'd need to keep polling the API.

 

[NicB72]

I have read through this thread and I am still having a problem with one particular API call.
Its the set charge limit call

https://owner-api.teslamotors.com/api/1/vehicles/{vehicle_id}/command/set_charge_limit?percent={limit_value}

this gets converted into
https://owner-api.teslamotors.com/api/1/vehicles/{vehicle_id}/command/set_charge_limit?percent=80

yep I put the right vehicle_id in that spot. I know the format works as headlights, horn, charge port, lock/unlock all work.

what ever it never sticks and instead always gets set to 50%


HELP

 

[LastGas]

@NicB72, what response do you get from the Post?

 

[NicB72]

@NicB72, what response do you get from the Post?

I get a 200 response so its all good but the value is always set to 50 no matter what I pass in.
and response is...

{"response":{"reason":"","result":true}}

Tesla Model S JSON API · Apiary shows throwing it on the end of the url and I have even tried json encoding "percent=80" and throwing it in the httpbody but still always 50

its something to do with the value I am sure but I don't know what.

 

[cryptyk]

I have read through this thread and I am still having a problem with one particular API call.
Its the set charge limit call

https://owner-api.teslamotors.com/api/1/vehicles/{vehicle_id}/command/set_charge_limit?percent={limit_value}

this gets converted into
https://owner-api.teslamotors.com/api/1/vehicles/{vehicle_id}/command/set_charge_limit?percent=80

yep I put the right vehicle_id in that spot. I know the format works as headlights, horn, charge port, lock/unlock all work.

what ever it never sticks and instead always gets set to 50%


HELP

You have the command correct, but the percent parameter needs to be a post parameter instead of a query parameter.

JavaScript:

request( {
            method: 'POST',
            gzip: true,
            url: portal + '/vehicles/' + vid + '/command/set_charge_limit',
            headers: { 'Authorization': 'Bearer ' + bearerToken, 'Content-Type': 'application/json; charset=utf-8', 'User-Agent': user_agent, 'Accept-Encoding': 'gzip,deflate' },
            form: {
                "percent" : percent.toString()
            }
        }

 

[NicB72]

You have the command correct, but the percent parameter needs to be a post parameter instead of a query parameter.

JavaScript:

request( {
            method: 'POST',
            gzip: true,
            url: portal + '/vehicles/' + vid + '/command/set_charge_limit',
            headers: { 'Authorization': 'Bearer ' + bearerToken, 'Content-Type': 'application/json; charset=utf-8', 'User-Agent': user_agent, 'Accept-Encoding': 'gzip,deflate' },
            form: {
                "percent" : percent.toString()
            }
        }

thanks. So I am doing this in swift and I also tried to put the percent in the body as well and still no joy

 

[NicB72]

thanks. So I am doing this in swift and I also tried to put the percent in the body as well and still no joy

Fixed it. For those using Swift, its not a query parameter and its not in the body. use session uploadTask