2025 API Changes Development

[metheos]

For discussing implementation of the new API endpoints and whatnot.

https://github.com/metheos/OnStarJS/tree/GM-API-v3

[metheos]

@BigThunderSR Give this branch a try with your account.
There is a completely new API for some of the EV-specific stuff, but once I got the app unpinned I was able to see the new API requests for the regular stuff as well. The changes in here so far are only for the new non-EV specific requests. I think the JSON shapes of the responses have changed a bit, but the names and substructures look similar.

I updated everything to use the new endpoints.

most of the vehicle commands are more or less the same.

getAccountVehicles is now a graphQL request.

location is completely different, it's its own endpoint with a GET param for a refresh and then poll for updated location.

diagnostics is completely different. there doesn't seem to be a way to request a 'live' update, you just get whatever data is most recent from Onstar. You also just have the one healthStatus endpoint that returns everything with timestamps of when they were last ran, you don't have the ability to post specific diagnostics to run. BUT the diagnostic data that gets returned seems to match what we were getting on the old version.

[BigThunderSR]

I was just about to respond here when you posted in the related thread. 🙂 I'll try to test this out sometime today.

I guess they really don't want us to be able to use their API based on the changes they seem to be making. 🙃

Thanks for your help as always!

[metheos]

I'm sure they don't really want us to use it. But to be fair I think they're just trying to improve things. The new endpoints seem faster and make sense from the perspective of their app. I was really just glad to see that the data returned seems to be the same, although it might be structured differently. I never really looked at the API responses much in the past.

I'm not sure if we should:

1. try to restructure the responses to look like the old data
2. just pass the responses along and make the downstream apps deal with the changes (mqtt/etc)
3. create our own data types and perform the transformations in OnstarJS to fit this and future changes into our own-designed data.

[BigThunderSR]

I get what you mean about giving them the benefit of the doubt that they did this to improve things, but if that were the primary motivation, I'm not sure they needed to cripple the existing API to the point of making it unusable for us. 🤷🏽‍♂️

In any case, I'd like to see if we can make this minimally painful to dependent projects (since I happen to manage the two primary ones 😅) if at all possible. Therefore, the priority for me would ideally be Option 1. While Option 3 is definitely better longer-term, I'm not sure I want to put in the effort just yet, only to have them figure out another way to block us after all of that.

This is just where I'm at without having had a chance to test your changes here, so this may change after I've had a chance to take a look at things.

Thanks again!

[metheos]

I would sunset an older API once I replaced it. No reason to maintain 2 if my app is the only thing using it!

I'm happy to reshape the new responses, I just don't have examples of the old ones. So just lmk what we need the output to look like once you get a chance to look at the new stuff and I'll make it happen. I'll probably just create types for our expected data based on what you tell me and we'll go from there.

[BigThunderSR]

I can't argue with that first part. 😅

[BigThunderSR]

@metheos, the default test:functional is giving me more diagnostic data than I ever knew was being collected by the mothership for my ICE vehicles!

I should be able to modify the downstream dependent programs to parse the output from this new diagnostic goldmine although it might take me a while and cause some breakage. It seems to be better than the other options as of now (yes, I'm going with Option 2 now although that may change again as I churn through the process). 😄

I did have to make a change to rollup.config.js to be able to run build:

  output: [
    { file: pkg.main, format: "cjs", exports: "auto" },
    { file: pkg.module, format: "esm", exports: "auto" },
  ],

What all do you need to do to be able to maintain this list of commands from the existing state (if any)?
https://github.com/BigThunderSR/OnStarJS?tab=readme-ov-file#commands

Thanks much as always for your assistance!!!

[metheos]

I already updated it to use the new endpoint for the vehicle commands. I didn't test all of them, but the ones I tested do work.
I removed a couple that don't seem to be relevant any more from the OnStarApiCommand because they're implemented separately. (connect,location). I also updated lockDoor to just lock/unlock based on my test results.

[metheos]

The functional test should indicate the cancelAlert call goes through correctly.
The new urls are like https://na-mobile-api.gm.com/veh/cmd/v3/lock/

[BigThunderSR]

I already updated it to use the new endpoint for the vehicle commands. I didn't test all of them, but the ones I tested do work.
I removed a couple that don't seem to be relevant any more from the OnStarApiCommand because they're implemented separately. (connect,location). I also updated lockDoor to just lock/unlock based on my test results.

I'm juggling too many things right now, so sorry in advance for any stupid questions.

How do you initiate a lock versus unlock for the trunk vs the doors now?

Thanks!

[metheos]

I updated the command variables list. It's all still the same variables and function calls. But lockdoor and unlockdoor internally map to the strings lock and unlock. So it should work the same as before.

…

On Mon, Sep 22, 2025 at 9:53 PM BigThunderSR ***@***.***> wrote: *BigThunderSR* left a comment (metheos/OnStarJS#1) <#1 (comment)> I already updated it to use the new endpoint for the vehicle commands. I didn't test all of them, but the ones I tested do work. I removed a couple that don't seem to be relevant any more from the OnStarApiCommand because they're implemented separately. (connect,location). I also updated lockDoor to just lock/unlock based on my test results. I'm juggling too many things right now, so sorry in advance for any stupid questions. How do you initiate a lock versus unlock now? Thanks! — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDD6ZKYRFEU7RBFYR4HZ7D3UCYY7AVCNFSM6AAAAACHDPMVV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMRSGE3TOMZTHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[metheos]

I pushed the change to rollup.config
I also created a little script for testing the functions in RequestService interactively.

Select an action:
1. getAccountVehicles()
2. diagnostics()
3. location()
4. start()
5. cancelStart()
6. lockDoor(options)
7. unlockDoor(options)
8. lockTrunk(options)
9. unlockTrunk(options)
10. alert(options)
11. cancelAlert()
12. toggle checkRequestStatus (client)
13. Exit
Enter choice number:

[metheos]

honestly, I don't know what these commands are supposed to do. I've never used them:
12. chargeOverride(options)
13. getChargingProfile()
14. setChargingProfile(options)

Looks like they are some of the things moved to the EV specific API. So I'll just remove them for now and we can focus on core API functionality before expanding into that one.

[BrettEBowman]

honestly, I don't know what these commands are supposed to do. I've never used them: 12. chargeOverride(options) 13. getChargingProfile() 14. setChargingProfile(options)

Looks like they are some of the things moved to the EV specific API. So I'll just remove them for now and we can focus on core API functionality before expanding into that one.

Those would be EV specific. And, it would definitely be nice for the implementation to support (at least some of) them for those of us EV owners.

You can configure the car so that when you plug it in to charge at home, it will delay the charging until a later time (when the electric rates are lower). But, if you want it to charge immediately, you can "override" the delay. I would guess that the chargeOverride would let you query/control that override functionality.

You can also configure how full to charge (80%, 100%, etc.), the amp limit (at least for Level 1 charging), etc. I would presume that the getChargingProfile and setChargingProfile calls would allow you to query/control those types of settings.