REST API Deprecated

[iqtedar123]

Looks like they are deprecating the REST API.
https://github.com/teslamotors/vehicle-command?s=09
Seems we have to register our apps with Tesla now.
Thoughts?

[Urkman]

I tried to create a developer account and register my app, but I only get an error: "unable to onboard app"...

[iqtedar123]

I think most of us will have to shutdown our projects since we were relying on the REST API directly.
Looks like Tesla wants developers to register and pay for the API (most likely companies like Hertz etc will enroll) since they want to launch an app store.
Sad news indeed.

[SylvainGa]

Shit. Tesla's third party apps where one thing that made Tesla stands out. Sucks that they want to kill it 🙁

[tomhollander]

@SylvainGa

I got up to that page. Not sure what to enter since my app doesn't use any servers on my side.

For the Origin URL, this needs to be an actual website which you own, as you'll need to upload keys there as part of the account registration process. I used a free Azure storage account for mine. Your actual app does not need to integrate with this URL.

The Reply URL can be a fake URL like blah://blah for a native client app. Needs to be real for a web app.

I don't know what the Return URL does.

[SeBsZ]

Anyone else getting the "unable to onboard app" error after entering everything? I'm pretty sure my URLs are valid.

What can I do to continue?

[westerlund]

@SeBsZ same

[purcell-lab]

I think most of us will have to shutdown our projects since we were relying on the REST API directly.
Looks like Tesla wants developers to register and pay for the API (most likely companies like Hertz etc will enroll) since they want to launch an app store.
Sad news indeed.

No need to start spreading FUD until we have the details. A documented and supported API from Tesla is a good thing and much better than trying to constantly reverse engineer an unofficially supported API, which can be switched off at a moments notice.

OAuth authentication is an industry standard and there are lots of authentication providers out there, including the ability to host your own OpenSource OAuth server. The legacy API currently uses OAuth authentication so the apps already have a level of OAuth compatability.

Yes existing apps will need to migrate to the new framework, but the fact that Tesla have provided a documented RestAPI and proxy server which appears to have more functionality than the current undocumented API does give me hope. Looks like the developer tier is still free, so let's not scare the horses too early.

Some folks have this working already in their dev environments:
#763 (comment)

[iqtedar123]

This is a discussion post. So a little bit of FUD should be allowed. 😅
Just sharing what other publications are reporting:
https://www.notateslaapp.com/news/1653/tesla-creates-official-apis-for-third-party-services-to-start-charging-for-usage?s=09

Totally agree that having official support for the API is great.
However it does come at the cost of indie developers who now have to apply for the developer program and will most likely be rejected (for various reasons).

[BJReplay]

I got up to that page. Not sure what to enter since my app doesn't use any servers on my side.

Those aren't servers, per se, but you'll need to do a bit of work for OAuth.

Their expectation seems to be that OAuth requests will come from a domain with a redirect and return.

It might be as simple as setting up DNS entries to get past this screen, and using those same DNS entries in your app.

You might need these to exist when you register.

I am a few days away from testing this (just had shoulder surgery, so typing with my wrong hand), but I'm the same situation as you, but I think I know enough about OAuth to be dangerous.

Let's keep this discussion going.

[Rockster160]

I'm a back end web developer- I'm quite familiar with the ins and outs of Oauth. Don't have much experience with the 3rd party Oauth services, but I'm happy to answer questions or help out getting an actual system set up.
It is very likely you need a DNS and simple server running in order to get it to work.

[SylvainGa]

Thanks

Does the server need a static IP address or can a dynamic DNS service like duckdns work?

[Rockster160]

Yep! Dynamic IP addresses should work with Oauth in general- although I'm not sure about Tesla's API directly. I'll say it's very unlikely they have an issue with dynamic ips, but you never know. 😂

[tomhollander]

For anyone using my TeslaAuth library for C#/.NET, I've managed to get this library to work with the Fleet API. The changes haven't been merged yet and testing/feedback would be appreciated. Once it's confirmed to work for people besides myself, I'll merge and push to Nuget.

tomhollander/TeslaAuth#36

[jonasman]

looks correct to me. maybe some problem in the url encoding?
Unless your hidden values are incorrect?

[Urkman]

It works when I remove the header "--header 'Content-Type: application/x-www-form-urlencoded' "...
Strange...

[Urkman]

So, one step further :)
I registered my app using the "partner_accounts" endpoint with a "partner token". This worked fine.

But if I want to call a vehicle endpoint, it gives me "Account **** must be registered please see https://developer.tesla.com/docs/fleet-api#register".

Did you manage to call a vehicle endpoint of the new API?

[Urkman]

Ok, fount it... It was just the url. I needed "https://fleet-api.prd.eu.vn.cloud.tesla.com", so "EU" and "NA" :)
So, now it works for me :)

[leovolwahsen]

I also made some progress here. The "authorize" request works fine and the callback url is called with a "code" inside. But when I then try to create the token using the "token" request I always get a bad_request (400). But without any error message. Any ideas on this?

@Urkman could you help me understand how you got the value for code? The other parameter I manage to get...

[tomhollander]

For anyone using my TeslaAuth library for C#/.NET, I've managed to get this library to work with the Fleet API. The changes haven't been merged yet and testing/feedback would be appreciated. Once it's confirmed to work for people besides myself, I'll merge and push to Nuget.

This has now been released as v3.0.0 of the library (it still also works for the Owner API)

[BJReplay]

I've managed to get this library to work with the Fleet API.

That's great news, I look forward to testing this. I'll be a few days away (post shoulder surgery - I don't really want to re-factor just typing with my wrong hand).

I've been using a source code version for a while as I ran into an issue with the Newtonsoft.Json JSON library that I used in my app that was incompatible with the version in your library (possibly due to me needing (?wanting) a newer version, or a .Net Framework version issue, so will be keen to report back on this, too. I note from reviewing the PR that you considered moving away from it, but didn't.

[jonasman]

The old api might not be dead as Tesla wrote this in the command api repo:

Pre-2021 Model S and X vehicles will continue to support the full REST API, and do not support the new protocol.

[samosss]

I have a Model S 2019 build (but upgraded from HW2.5 to HW3 computer), and it seems like REST API is not supported on mine (Australia, if that makes any difference)

[FlorianR-Hub]

Hello !

Does anyone know how to integrate the Vehicle Command SDK into an Android (or even Flutter) application?

The SDK has been developed using the Go language. It's normally possible to compile Go code so that it can be used by mobile applications, but it looks a bit tricky.

Tesla also offers a proxy, to convert REST API calls to their new vehicle-command protocol.
But if I've understood correctly, this requires you to have your own proxy, which implies additional infrastructure costs. Not ideal for small developers...

Are there any other solutions?

[LandonMoss]

Add the SDK Dependency:

If the Vehicle Command SDK supports Flutter, you can add it as a dependency in your pubspec.yaml file.
yaml
Copy code
dependencies:
vehicle_command_sdk: ^version
Integrate Native Code (if necessary):

If the SDK is written in native code (Java/Kotlin for Android), you might need to create a Flutter plugin that acts as a bridge between Flutter and the native SDK.
Initialize and Use the SDK:

In your Flutter code, initialize the SDK and use its functions. This often involves calling native methods through the Flutter plugin.
dart
Copy code
import 'package:vehicle_command_sdk/vehicle_command_sdk.dart';

void main() {
VehicleCommandSDK.init(apiKey);
}
Handle SDK Events:

If the SDK triggers events or callbacks, make sure to handle them appropriately in your Flutter code.

[FlorianR-Hub]

Thank you for your answer.

However, these are the obvious solutions, and there is currently only an SDK developed in GO.
I'm not aware of any public Flutter/Dart dependencies developed by Tesla or anyone else.
For native code, same thing, you'd have to do it yourself.

The point of my previous message was to find out if there were other solutions already possible at the time that I'd missed.

In the meantime, there's been some news from the Tesla SDK on Github. They've added documentation explaining how the protocol works to send commands to Tesla vehicles.

I don't see Tesla coming up with a dependency for Android or Flutter applications, so I think there are only 2 possibilities for those who want to integrate this SDK in mobile apps :

• wait for someone to make a dependency available
• write the dependency yourself

[SylvainGa]

Hello !

Does anyone know how to integrate the Vehicle Command SDK into an Android (or even Flutter) application?

The SDK has been developed using the Go language. It's normally possible to compile Go code so that it can be used by mobile applications, but it looks a bit tricky.

Tesla also offers a proxy, to convert REST API calls to their new vehicle-command protocol.
But if I've understood correctly, this requires you to have your own proxy, which implies additional infrastructure costs. Not ideal for small developers...

Are there any other solutions?

The method I chose, which made some of the users of my (free to use) app unhappy is to strip the Tesla code and replace it with the equivalent Tessie API commands. Of course, you need a (paid) Tessie account to use their API (which made some users unhappy), but it's simple to use and supported by the new Tesla API.

I'm not planning on installing/supporting a publicly available proxy server that could make me responsible if something/someone gets hacked through it because I failed to update it/or through a zero day exploit. No thank you, not for me.