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.
I found it quite ironic that we can track and control our cars from our phones (and tablets) but not from the big computers that we sit in front of, but I share the concern of sending credentials via a third-party website, so I created a bookmarklet that layers a user interface on the API endpoint. It is very basic right now, just allows you to login and has links to most of the functions (since they are strangely all GET requests), but I plan to make it more usable over time.

TeslaTime

All thanks to timdorr for documenting the API!
 
I found it quite ironic that we can track and control our cars from our phones (and tablets) but not from the big computers that we sit in front of, but I share the concern of sending credentials via a third-party website, so I created a bookmarklet that layers a user interface on the API endpoint. It is very basic right now, just allows you to login and has links to most of the functions (since they are strangely all GET requests), but I plan to make it more usable over time.

TeslaTime

All thanks to timdorr for documenting the API!


I can't seem to get this to work...???
 
I found it quite ironic that we can track and control our cars from our phones (and tablets) but not from the big computers that we sit in front of, but I share the concern of sending credentials via a third-party website, so I created a bookmarklet that layers a user interface on the API endpoint. It is very basic right now, just allows you to login and has links to most of the functions (since they are strangely all GET requests), but I plan to make it more usable over time.

Cool, but aren't you worried about opening yourself up to potential CSRF attacks? Since the API uses GET requests, it is very vulnerable to CSRF if you are actually logging into the mobile app portal with the browser. Unlikely to occur in real life, but unfortunately way too easy to exploit given their current API design.
 
hey guys, is there a wiki, or a centralized post with current links to the projects you all are working on that are avail for public testing?

i'm a computer nerd and get most of this stuff, but haven't kept up on programming for years, and no time to jump back in now, but i'd love to use/try out the interfaces you're working on. i see a couple links to web interfaces, but there are a few maybe standalone projects people are working on, e.g. cli interface, scripts, that sound very interesting too.. if you guys want, will you post links to your code, sites, whathaveyou, in a central spot? is the first post of this thread editable to do that? or if he doesn't want to, maybe another way to do it?

just throwing that out there. i'm interested in keeping up with what you guys are doing, and i'm sure many others are too, but don't have the time to follow each post here. thanks for all the research and sharing. very cool.


dt
 
It was hot today in California so I wrote a command line climate monitor and HVAC controller

8573246292_3361647e14_b.jpg
 
I can't seem to get this to work...???

Feel free to PM me or add an issue on Github with the steps to reproduce the problem.

- - - Updated - - -

Cool, but aren't you worried about opening yourself up to potential CSRF attacks? Since the API uses GET requests, it is very vulnerable to CSRF if you are actually logging into the mobile app portal with the browser. Unlikely to occur in real life, but unfortunately way too easy to exploit given their current API design.

Yes, it is. I should document this on the instructions so people would use caution, or Incognito mode.
 
Thanks a lot for the awesome information on this thread guys, and the cool reverse engineering.

Using the information here I was able to whip up a nice C# 5.0 headless service that constantly polls the car's charging state and location via streaming, runs 24/7 on Amazon EC2 and stores the data in DynamoDB so that I can do some cool analysis later on of everywhere I've ever been with the car.
 
Thanks a lot for the awesome information on this thread guys, and the cool reverse engineering.

Using the information here I was able to whip up a nice C# 5.0 headless service that constantly polls the car's charging state and location via streaming, runs 24/7 on Amazon EC2 and stores the data in DynamoDB so that I can do some cool analysis later on of everywhere I've ever been with the car.

I'm not sure what you mean by "constantly", but I recommend you have a healthy amount of sleeping in there. Keep in mind that Tesla can change this protocol at any time, and we want to stay on their good side, so that maybe they won't change it -- or even better -- actually publish the protocol.
 
I'm not sure what you mean by "constantly", but I recommend you have a healthy amount of sleeping in there.

Constantly means:

- I query charge_state every 60 seconds.
- I query drive_state every 30 seconds.
- Once drive_state.speed returns non-null (meaning the car started moving) I start a streaming session, which I stop right away once the car goes into Park again.

I'm seeing quite a few duplicates in charge_state data, so I can easily make that 5 minutes instead. The drive_state query period is relatively low to start streaming soon after I start driving (15 seconds in, on average).

For comparison, the iPhone app seems to be polling this data every 15 seconds.
 
Last edited:
Okay, I admit it...it's been a while since I did a lot of coding but hey, how hard could it be? Well, I guess I'm just not as good as I thought because I can't seem to get my app to connect to the portal - at least not enough to get any information back out of it. Looking at the documentation this group has put together (wow, fantastic job by the way!) I make a POST call to portal via an HttpWebRequest object (I'm using C# .NET) that includes the username and password variable and get a response back from the portal that would seem to indicate I successfully logged in. It contains a single cookie (_s_portal_session) and the stream includes an href that reference "logout" instead of "login" and a "Welcome to the portal app." message. (if I used an invalid username/password the stream is clearly different and looks that same as if I just directed a browser to the /login page). The documentation however says I should expect 2 cookies (session and user_credentials) and so when I try to make my next request to retrieve something like the vehicles (even with the session cookie included) I basically get a response stream that looks like I am not logged in. Anyone got any ideas? Do I need to abandon my trusty .NET and start learning something else? :) Any help would be greatly appreciated. If I can get the .NET stuff to work I will happily share the code with anyone that wants to run their own web page.
 
CaptMike,

I was able to use .NET and C# very successfully for my app. Are you sure you're making the POST request properly? Are you sending the POST parameters with the proper form encoding?

I'd suggest trying the WebClient class instead. it's a higher-level helper class that wraps HttpWebRequest and makes the code easier, doing all the POST formatting for you. Take a look at the sample code below (I'm using C# 5.0 async here, but if you're not familiar with that you can just drop async/await and use blocking calls for now):

Code:
// Log in to the portal with the given credentials
private async Task LogIn(string username, string password)
{
    // Set up POST parameters.
    var values = new NameValueCollection() 
                 { 
                    { "user_session[email]", username },
                    { "user_session[password]", password }
                 };

    // Create a cookie jar to hold the returned cookies.
    var cookies = new CookieContainer();
    var webClient = new MyWebClient(cookies);

    // Perform the POST request.
    await webClient.UploadValuesTaskAsync("https://portal.vn.teslamotors.com/login", values);

    // At this point 'cookies' should have the two cookies you need for all future requests.

    // Get the list of vehicles (using the cookies from the container above).
    string vehiclesResponse = await webClient.DownloadStringTaskAsync("https://portal.vn.teslamotors.com/vehicles");

    // ...
}


// Custom web client that sets the cookie container on outgoing HTTP requests.
private class MyWebClient : WebClient
{
    public MyWebClient(CookieContainer cookies)
    {
        Cookies = cookies;
    }

    protected override WebRequest GetWebRequest(Uri address)
    {
        HttpWebRequest request = (HttpWebRequest)base.GetWebRequest(address);
        request.CookieContainer = Cookies;
        return request;
    }

    public CookieContainer Cookies
    {
        get;
        private set;
    }
}
 
Quite an eclectic group of programmers here. We've now collectively written clients in C#, Java, Node.js (JavaScript), Python, Ruby, and shell scripts + curl. Did I miss any?

Even more amazing, with over 250 posts we somehow avoided a religious flame war over which programming language is the "best". :)
 
Quite an eclectic group of programmers here. We've now collectively written clients in C#, Java, Node.js (JavaScript), Python, Ruby, and shell scripts + curl. Did I miss any?

Even more amazing, with over 250 posts we somehow avoided a religious flame war over which programming language is the "best". :)

That's because everybody knows it's Lisp. But Python will do.