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

PCMc

Member
Jul 1, 2016
76
55
Columbus, IN
I have my refresh token logic fully integrated into my overall routine with it tracking token expiration and automatic renewal.

Does anyone know of any reason to save the short refresh token that is provided in Step 4 along with the access token?

For my current implementation I'm saving the full step3 response/token information to a separate file so it can be read back in when needed to do Step 5/Step 4 to get new access token. I'm already saving the full token response from Step 4 to a file so I can reuse it any time I need to stop and restart the program.

I've debated replacing the unused Step 4 short access token in the Step 4 response with the Step 3 long refresh token. This way I'd have just a single token file saved that has everything, current access token, created and expires in timestamps, along with the long refresh token. Each time I refresh Step 4, I'd just transfer the Step 3 long access token over. The purist in me would say this is more efficient, eliminates one set of file read/writes and one file to access, but the other side of me says 'what difference does it make, don't mess with it' given it works.
 

apacheguy

S Sig #255
Oct 21, 2012
5,075
1,238
So Cal
One thing that I found a bit puzzling is that you often have to retry step 2 multiple times in order to retrieve the code. I see @PCMc has an automatic retry loop that I’ll need to implement in my code. Anyone understand why Tesla’s API can‘t simply respond on the first try?
 

apacheguy

S Sig #255
Oct 21, 2012
5,075
1,238
So Cal
I'm using the above PHP code which has been updated for the new SSO auth scheme. It fails on Step 2 (obtain auth code). As far as I can tell, it correctly retrieves the "hidden" form inputs and cookie value, but a subsequent call to the /oauth2/v3/authorize endpoint returns HTTP 403 (forbidden) instead of HTTP 302 (redirect).

Several other users commented on github that it recently stopped working for them so I guess I'm not alone. Anyone figure out a fix?
*** SOLVED ***

Things I learned:
1. There are multiple cookie values that are passed to the client in step 1. All cookie values must be set for subsequent requests.
2. It is helpful to have a retry loop on step 2 as you will often receive HTTP 403 for no apparent reason.
3. The cookies must be passed in steps 3 and 4. For some reason, the individual who wrote the PHP code I referenced only decided to pass the cookie in step 2.
 
Last edited:

markb1

Active Member
Feb 17, 2012
3,034
640
San Diego, CA
*** SOLVED ***

Things I learned:
1. There are multiple cookie values that are passed to the client in step 1. All cookie values must be set for subsequent requests.
2. It is helpful to have a retry loop on step 2 as you will often receive HTTP 403 for no apparent reason.
3. The cookies must be passed in steps 3 and 4. For some reason, the individual who wrote the PHP code I referenced only decided to pass the cookie in step 2.

I didn't find it necessary to pass any cookies for step 3 and 4, though I suppose something could have changed since I did my initial login.
 

PCMc

Member
Jul 1, 2016
76
55
Columbus, IN
I have a question about anyones experience with a couple of the values returned by the charge state API call.

I logged data today for a charging session with my Gen1 UMC at 240V / 40 amp. Everything with the actual charging worked fine and I logged basic charging parameters through my charge such as SOC, reported rated miles, etc.

One looks odd are the values returned for "charge_energy_added" and "charge_miles_added_rated". Both values report 0 for about the first 20 minutes. At that point both values start counting up, with the miles_added value tracking 1:1 with the incremental range reported through the end of the charging session. Net of this is that when charging completes both values are under reported by the amount of miles/energy added over that first 20 minutes of charging.

Anyone else ever notice anything like this? As I've commented in other posts, I'm converting over from VisibleTesla finally, gradually building up my own logger to capture similar data. That's where I was looking at the "charge_energy_added" value today to see how it equates to the value that VT would report when I'd generate a charging sessions report.

Probably be about a week before I'd plan to charge again and have another dataset to see if today's experience is consistent or a fluke.

Thanks!
I'm still curious if anyone has ever paid attention to the "charge_energy_added" and "charge_miles_added_rated" values from the call for the charge data.

I've continued to notice that the values do not increment until partway through my charging session.

For reference, I have my charge routine set to start charging at SOC = 51 and stop at SOC=70. It's done this multiple cycles now over the past month. The data is very consistent that the values only start to increment when SOC reaches 65. From 65 to 70 the charge_miles_added_rated matches with increase in the Range value.

What I just realized is the value of 65 just happens to match the ending SOC from the last time I supercharged in early January.

Anyone else noticed behavior like this? I won't be back in the US for over a month so am not able to test it out to see if I go supercharge to a different value is the parameter somehow resets.
 

brianman

Burrito Founder
Nov 10, 2011
17,519
2,982
Step 1 just seems to time out for me no matter what I throw at it.

Using C#.

Postman requires a login now so I haven't looked at Joe's sample yet.
 

brianman

Burrito Founder
Nov 10, 2011
17,519
2,982
Step 1 just seems to time out for me no matter what I throw at it.

Using C#.

Postman requires a login now so I haven't looked at Joe's sample yet.
Update: Well that's interesting. My latest change adjusted the base64 encoding code_challenge to be "url friendly" and suddenly I'm getting html back instead of non-response. FYI for others that run into this.

Update: Well. It worked once. Timing out again on 2nd+ attempts. Sigh.
 
Last edited:

PCMc

Member
Jul 1, 2016
76
55
Columbus, IN
Update: Well that's interesting. My latest change adjusted the base64 encoding code_challenge to be "url friendly" and suddenly I'm getting html back instead of non-response. FYI for others that run into this.

Update: Well. It worked once. Timing out again on 2nd+ attempts. Sigh.
If you've pinged it too much in a short period of time it will lock you out. That can be a problem when you're trying to debug. You may find you need to wait 30 minutes after a failed attempt before you try it again. I recall there being comments about this earlier in this thread.
 
  • Informative
Reactions: brianman

brianman

Burrito Founder
Nov 10, 2011
17,519
2,982
If you've pinged it too much in a short period of time it will lock you out. That can be a problem when you're trying to debug. You may find you need to wait 30 minutes after a failed attempt before you try it again. I recall there being comments about this earlier in this thread.
Stage 1 is slow but seems to be finally working. Stage 2 is giving me the connection closed issue. I'm trying switching to the TeslaAuth nuget package, but it's failing as well.

It's starting to feel like I may be better off seeing a full Fiddler trace of a valid interaction rather than shooting in the dark.

If Tom Hollander is on here, I'm seeing "A task was cancelled" from TeslaAuth. Not super helpful information.

C#:
using TeslaAuth;

...
   
var authHelper = new TeslaAuthHelper("MyApp");
var tokens =
    await authHelper.AuthenticateAsync(email, pass, null, TeslaAccountRegion.USA);

Update: Adding these 4 lines (copied from the test in the repository) seems to make it work:
Code:
        ServicePointManager.FindServicePoint(new Uri("https://auth.tesla.com")).ConnectionLeaseTimeout = 60 * 1000;
        ServicePointManager.FindServicePoint(new Uri("https://auth.tesla.com")).ConnectionLimit = 10;
        ServicePointManager.FindServicePoint(new Uri("https://owner-api.teslamotors.com")).ConnectionLeaseTimeout = 60 * 1000;
        ServicePointManager.FindServicePoint(new Uri("https://owner-api.teslamotors.com")).ConnectionLimit = 10;
 
Last edited:

About Us

Formed in 2006, Tesla Motors Club (TMC) was the first independent online Tesla community. Today it remains the largest and most dynamic community of Tesla enthusiasts. Learn more.

Do you value your experience at TMC? Consider becoming a Supporting Member of Tesla Motors Club. As a thank you for your contribution, you'll get nearly no ads in the Community and Groups sections. Additional perks are available depending on the level of contribution. Please visit the Account Upgrades page for more details.


SUPPORT TMC
Top