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.
If you sniff the traffic locally (I.e. Packet sniffer installed on the phone itself), then shouldn't it be readable? That way you don't have to forge a self signed cert.

Anyone think that they can decompile the mobile app and extract the necessary private key?

---updated---

They are using certificate pinning. On ios there is a folder called SSLpins.plist in the library folder.


Did anyone find a way around this? I have most things working, but was hoping to use fiddler to see some examples of the format of the 'upcoming_calendar_entries' command... but wasn't able to get the official apps to connect (iOS or Android)
 
I got finally the fully format of the 'upcoming_calendar_entries', I'm pushing a calendar to the car and is accepted however nothing is shown on the screen, there are two fields on the json payload 'uuid' and 'phonenumber', to simulate a android device I even sent the same uuid and phonenumber of the android device and the car still doesn't show anything.

I bet there are some extra steps happening with the Bluetooth, I think the calendar functionality works in conjunction with the Bluetooth and can't be activated by its own only using REST, unless Tesla release how integration works with Bluetooth I think we are out of luck to integrate the calendar.
 
My suspicion is that Bluetooth is only needed to determine which device is connected and hence which calendar to display. For cars with more than one driver, this is the obvious solution since multiple calendars would be synced and the car would be left guessing as to which to display.
 
Just tested the defroster-commands, and I get "unknown command" even with a 6.0 car. But I use the Android app-id and secrets, so it _might_ be a possibility that they have rigged the API to allow different commands from different apps. It would make sense to disable IE. remote start from a web app, or filter out other commands to only certain apps.

Just tested the defroster-commands with the client-id and secret from the iPhone app as well, and they still only give "unknown command".
So I guess the commands are just added to the backend app code (but maybe not to the user interface?) but not implemented in the server code yet.

I also tested the dev-api (with the proper id/key-combo) but only got a 401 unauthorized when trying to request a token there...
 
My suspicion is that Bluetooth is only needed to determine which device is connected and hence which calendar to display. For cars with more than one driver, this is the obvious solution since multiple calendars would be synced and the car would be left guessing as to which to display.

This was my thought since the car needs to hold one calendar for each driver, however after several unsuccessful attempts I tried to send the same information that is been send by an android device, this was just to know if REST was enough to modify the calendarand nothing happen on the console.

Basically my test was, connect the android phone to the car:
- Bluetooth is paired
- Calendar is displayed on the car
- From a PC call 'upcoming_calendar_entries' using the same uuid and phonenumber data than the android phone, pushing a new calendar or even disabling the calendar in the REST API, nothing happen!!!!
- Also on the android device the Tesla app IS NOT RUNNING, and if I make changes on phone calendar a few seconds later the calendar is updated automatically on the car (don't need to open the app), so looks like the calendar integration is deeper than just REST API. Another theory is that the Tesla app register some callbacks with the OS, when the calendar is changed call the callback and push the new calendar to the car even when the app is not running, I don't know if it is possible to register callbacks on Android devices.
 
I started to look at the notification system, but it looks like it depends on third party services. And it does not look like it uses the "standard" API calls.
If someone have a dump of the traffic when a notification is added or changed it would be great.
 
I started to look at the notification system, but it looks like it depends on third party services. And it does not look like it uses the "standard" API calls.
If someone have a dump of the traffic when a notification is added or changed it would be great.

From what I heard you can register your own URL for notifications, that's great since won't be OS dependent, any app on any OS could subscribe.

You can just register the URL and wait for the notification to come, in the case of phone devices the notification has to be preprocessed on a server (cloud?) to be send to a specific OS and specific device notification mechanism, however standalone Apps on the desktop could also even listen on a port and subscribe for that url as long the firewall is open.
 
Do you know how to register an URL for notifications?
I don't have an iPhone, only android, and there are no settings in the app for notifications. I have neither seen any info about this in the car settings.

After searching the source code of the app I found a few interesting sections, and I am able to do some stuff, but it seems like the API-call needs a "device_type" and "device_token", which seems to be obtained internal android functions in the app.
I tested by creating a new server-key in Google Play Developer Console and sending this to /api/1/notification_preferences
I got a valid response, but it did not contain an URL and I can not find any references to a custom URL in the source (but I am not really fluent in java, so I might have missed something).

As far as I can see, the notifications are handled by using google cloud messaging (at least for android). However I have no idea how the notifications are sent from the car to the messaging service.
 
Push Notifications

Do you know how to register an URL for notifications?
I don't have an iPhone, only android, and there are no settings in the app for notifications. I have neither seen any info about this in the car settings.

After searching the source code of the app I found a few interesting sections, and I am able to do some stuff, but it seems like the API-call needs a "device_type" and "device_token", which seems to be obtained internal android functions in the app.
I tested by creating a new server-key in Google Play Developer Console and sending this to /api/1/notification_preferences
I got a valid response, but it did not contain an URL and I can not find any references to a custom URL in the source (but I am not really fluent in java, so I might have missed something).

As far as I can see, the notifications are handled by using google cloud messaging (at least for android). However I have no idea how the notifications are sent from the car to the messaging service.

Push notifications on modern smartphones have to go necessarily through the platform's cloud based notification infrastructure (GCM, APNS, WNS for Google, Apple and Microsoft respectively).
A 3rd party (i.e.: Tesla) server will have to register with these platform services and send the notifications to these servers who in turn will send then to the right device, app, etc.
All these services use pretty much the same principle described above and if you need more information on how android's variant works, you can find the documentation over here: https://developer.android.com/google/gcm/index.html

The point here is that even if you're able to trigger a new type of notification not shown in the UI, you'll only be able to receive it in your own phone through Tesla's app since Tesla's servers will be sending the notification to your platforms provider instead and unless you have a specific contract (in api terms) with Tesla yourself (which is what could be achieved with notification hubs, topic for another day) you won't be able to get the actual notification to your backend, desktop or whatever.
 
Thank you for the information.
I guess what I tried to do was to register my server as an android app, and thereby receiving the notifications from gcm to both my phone and my server.
I don't know if the system will notify all devices. What happens if you have several phones or tablets logged in with the same account in the Tesla app? Will they all receive the notifications?
If so, I guess it should be possible to create a fake device, that is actually a Web server or something, which should be able to receive the notifications as well.
 
@Olen - May I ask you how you are retrieving the ID in PHP for subsequent REST calls? With the previous API I had no issues, but last night I made the move to owner-API. Now, PHP is returning my ID in scientific notation, which is incompatible with the Tesla servers. But, not to worry, I'll just use a sprintf function which displays the number correctly; however it is xxx864 whereas if I run a curl command from terminal on my desktop if comes out to xxx571. I'm truly baffled as to how the first 16 digits are exactly the same and yet my last 3 digits are not.
 
Thank you for the information.
I guess what I tried to do was to register my server as an android app, and thereby receiving the notifications from gcm to both my phone and my server.
I don't know if the system will notify all devices. What happens if you have several phones or tablets logged in with the same account in the Tesla app? Will they all receive the notifications?
If so, I guess it should be possible to create a fake device, that is actually a Web server or something, which should be able to receive the notifications as well.

Actually all this command would be doing (and I'm just assuming here based on my knowledge of push notifications technologies) is signal to tesla's backend that you want to receive notifications on your device which as of now means iOS only since this feature is only enabled on this device (according to the Pub-Sub pattern).

Unless tesla are using aggregation technologies like Microsoft's notification hubs (documentation) they would have to implement push notifications on their backend individually for each platform for push notifications to work on top of code that would detect which platform and/or device you want notifications to be sent to. Imagine a scenario where you've got the official tesla app installed on an iPhone and an iPad but for whatever reason want to receive notifications on only one of those devices. What I'm describing here is part of the registration phase (also called the subscription phase) of the communication which is also platform dependent which may happen whether you want notifications to be sent to your device or not (it's a matter of implementation choice).

In general what you'd expect such a command to do is send to the 3rd party backend (Tesla in our case) among other things a set of IDs, one being related to the mobile app, one related to the device, and one related to the type of notification such as car alarm, charging, etc.

Having said that, the notification itself (the publication phase), even if it were to be sent via an aggregation service would still have to be sent to each individual platform's notification service (APNS, GCM or WNS) for the actual notification to be received by each device. In other words, since Tesla's servers would have to send notifications to these servers (or the aggregator server) there's no way for you to receive such a notification unless either tesla have implemented a similar pub-sub mechanism for 3rd parties and other types of platforms, or you somehow manage to convince Apple's or Google's push infrastructure that your code is actually an iOS or Android application.