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’m trying to register my site on the developer portal. It rejects the application stating “domain must be registered with a certificate authority.” My site uses TLS and my cert authority is ZeroSSL. It is recognized as a valid cert authority by all major browsers but perhaps Tesla doesn’t recognize it?
 
I’m trying to register my site on the developer portal. It rejects the application stating “domain must be registered with a certificate authority.” My site uses TLS and my cert authority is ZeroSSL. It is recognized as a valid cert authority by all major browsers but perhaps Tesla doesn’t recognize it?
I don't know about ZeroSSL. I have used an AWS hosted one (using Amplify). I could not get tesla to recognize my site either, until I changed the URL to include the prefix www. Based on Tesla’s example, I did not think that was required, but that solved the problem I think you are describing.

I am stuck on the next step: Generating a third-party token on behalf of a Customer . Which is ironic, since it is just for me :)

I can get the https://auth.tesla.com/oauth2/v3/authorize API to successfully work, but the returned code URL does not work right. I think my issues is I am unclear on what to put in the redriect_uri parameter. I am currently using https://auth.tesla.com/void/callback. That worked when using the unofficial APIs and sever python examples. But not anymore.....

And yes - my 1st post - sorry :)

Eric
 
@SmartPig you need to put the URI of your site which handles the oauth callback. The URI must match the one you listed on your developer application.

I’ve gotten this to work and it successfully generates an access_token. However, when I refresh the token, it only returns the access_token and not a new refresh token. Further calls to the refresh token API generate an error (login required).
 
I haven't had any success registering my 'app'. It has been explained to me on another forum that Tesla registers the apps on the domain level, not the Fully Qualified Domain Name (FQDN).

So in my unworking case, I have a free domain name from noip.com of https://mywebsite.ddns.net. The domain "ddns.net" is not owned by me and other entities could potentially be using mywebsite2.ddns.net.

So in my example, "ddns.net" is from a dynamic DNS provider. Even if Tesla would allow this (they probably blacklisted it) the chance is someone else has already registered an app using "ddns.net".

You need to use a domain you actually own with a unique domain name. I further noticed that Tesla has appended my unsuccessful application with a change to my uri. Where I wrote down https://mywebsite.ddns.net, they have replaced it with mywebsite.com is available for purchase - Sedo.com

Perhaps they even require a .com domain?
 
I haven't had any success registering my 'app'. It has been explained to me on another forum that Tesla registers the apps on the domain level, not the Fully Qualified Domain Name (FQDN).

So in my unworking case, I have a free domain name from noip.com of https://mywebsite.ddns.net. The domain "ddns.net" is not owned by me and other entities could potentially be using mywebsite2.ddns.net.

So in my example, "ddns.net" is from a dynamic DNS provider. Even if Tesla would allow this (they probably blacklisted it) the chance is someone else has already registered an app using "ddns.net".

You need to use a domain you actually own with a unique domain name. I further noticed that Tesla has appended my unsuccessful application with a change to my uri. Where I wrote down https://mywebsite.ddns.net, they have replaced it with mywebsite.com is available for purchase - Sedo.com

Perhaps they even require a .com domain?
Just buy your own domain name and point it to your ddns name with a CNAME record. I would think that should work.
 
  • Like
Reactions: robertvg
I'm got my old Model S working with the new API, but not my 2013 Model Y. My understanding is they are different, and I need the proxy server to communicate with the MY. I have my virtual key installed in the MY. I have the proxy server running. I can query the MS through the proxy server, but not the MY. (I just get a "not found" error.)

I turned on verbose logging from the proxy server, and to my surprise, it seems to be sending everything to the REST API, whereas I think the MY should go somewhere else.

Code:
2024-04-13T10:10:38-07:00 [info ] Received GET request for /api/1/vehicles/<YVIN>/vehicle_data
2024-04-13T10:10:38-07:00 [debug] Forwarding request to https://fleet-api.prd.na.vn.cloud.tesla.com/api/1/vehicles/<YVIN>/vehicle_data
2024-04-13T10:11:26-07:00 [info ] Received GET request for /api/1/vehicles/<SVIN>/vehicle_data
2024-04-13T10:11:26-07:00 [debug] Forwarding request to https://fleet-api.prd.na.vn.cloud.tesla.com/api/1/vehicles/<SVIN>/vehicle_data

How does the proxy server decide where to send the request? What am I missing, here?
 
I'm got my old Model S working with the new API,
@markb1 - Can you potentially point me to a simple resource on steps on how to get the new API set up for someone like me not that is not that savvy on the server communication side of things? Did you have to set up your one website and register it to do that, or were you able to do it via some other resource? I need to figure this out before they totally shut off the old API, as was indicated the were intending to do at some point.

Thanks!
 
@markb1 - Can you potentially point me to a simple resource on steps on how to get the new API set up for someone like me not that is not that savvy on the server communication side of things? Did you have to set up your one website and register it to do that, or were you able to do it via some other resource? I need to figure this out before they totally shut off the old API, as was indicated the were intending to do at some point.

Thanks!

I already had my own domain and webserver, so I used that. You'd have to register a domain through a registrar. I used Google Domains, but they sold that to Squarespace, and I don't yet know if should recommend that or not. Then you either host the webserver yourself, on on Raspberry Pi or something, or pay someone else to host it. (You need a hosting service that allows scripting.) I can try to help if you have specific questions.

I think the web server is just needed for a few things:

1) Host your public key (maybe needed just for setup.. they say you need to keep hosting it, but not sure when they actually need it outside of setup and pairing to car)
2) Accept the callback for the authorized request
3) Accept the callback for the code exchange

Once you have the code from step 3, and assuming you requested offline_access scope, you can just keep renewing the token, just like the owner API. So you don't need steps 2 and 3 again unless you want to access another account (or you let a refresh token expire, which takes 30 days, as I recall).
 
  • Like
Reactions: apacheguy and PCMc
Come to think of it, you don't really need a web server for steps 2 and 3. For 2, you probably need a web browser, but you could intercept the callback using the web developer tools built into the browser. For 3, you should be able to use curl to send the request and catch the redirect.
 
  • Like
Reactions: PCMc
@markb1 I can get the API to work, but as soon as my script requests a new access token using the refresh token it stops working. The access tokens seem to expire after only 8 hours or so. Here’s the error I get:

Code:
 "error": "login_required",
  "error_description": "Login required",
  "referenceID": "79392f4b-73a8-4d78-8cad-4f13eeb310b6-1711593002459"

I defined offline access in the scope.
 
@markb1 I can get the API to work, but as soon as my script requests a new access token using the refresh token it stops working. The access tokens seem to expire after only 8 hours or so. Here’s the error I get:

Code:
 "error": "login_required",
  "error_description": "Login required",
  "referenceID": "79392f4b-73a8-4d78-8cad-4f13eeb310b6-1711593002459"

I defined offline access in the scope.
That's odd. 8 hours does sound right about for expiration. Refreshing gets you a new access token, which should work for the next 8 hours, and a new refresh token.
 
Here's my refresh code. Does this look similar to yours? Am I missing anything?

Code:
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "https://auth.tesla.com/oauth2/v3/token");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_TIMEOUT, 30);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_SSLVERSION, CURL_SSLVERSION_MAX_TLSv1_2);
curl_setopt($ch, CURLOPT_HTTPHEADER, [
    'Content-Type: application/x-www-form-urlencoded',
    'Accept: application/json'
]);
curl_setopt($ch, CURLOPT_POSTFIELDS, 'grant_type=refresh_token&client_id=8377xxxxxxxxxxxxxxxxxxxxxxxx&refresh_token=' . $refreshToken);

$apiResult = curl_exec($ch);

curl_close($ch);
return $apiResult;
 
Here's my refresh code. Does this look similar to yours? Am I missing anything?

Code:
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "https://auth.tesla.com/oauth2/v3/token");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_TIMEOUT, 30);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_SSLVERSION, CURL_SSLVERSION_MAX_TLSv1_2);
curl_setopt($ch, CURLOPT_HTTPHEADER, [
    'Content-Type: application/x-www-form-urlencoded',
    'Accept: application/json'
]);
curl_setopt($ch, CURLOPT_POSTFIELDS, 'grant_type=refresh_token&client_id=8377xxxxxxxxxxxxxxxxxxxxxxxx&refresh_token=' . $refreshToken);

$apiResult = curl_exec($ch);

curl_close($ch);
return $apiResult;

Hmm.. it does look like it matches the documentation, but doesn't match what I'm doing. I'm passing the three parameters as JSON.

A snippet of my python code:

Code:
payload = {
    'grant_type': 'refresh_token',
    'client_id': client_id,
    'refresh_token': refresh_token
}

r = requests.post('https://auth.tesla.com/oauth2/v3/token', json=payload)