Oauth Flow Cloud and Local

I haven't see much documentation on gaining an access token without using createAccessToken manually in an application, so I did some researching and poking around into the local and cloud endpoints using the ifttt integration urls, and subbing in some of the urls and variables seen on ST.

The flows below are a replacement for the Smartthing's oauth flow

Enabling oauth in your application.
This one is probably known to most everyone, but including here just for completeness. In the app code section, create or click an existing app and click the Oauth and enable button. Make note of the client id and secret for later in the flow:


Authorization code
Build the url with the following parameters


client_id=client id of your app
redirect_uri=server url that will accept the code. In this case I'm using localhost so I can just grab the code when it returns.

The next screen will give you the option to either grant or deny the request and to set any devices you wish to give the app access to. You must have at least one preference in here to keep it from erroring out.

Once you click authorize you will be given the code in the url. Keep note of this.


Access Token
Take the code you received above and build a new link like below:


client_id=client id of your app
client_secret=client secret of your app 
code=code from the first call
redirect_uri=**Must be the redirect_uri from the first call**

The redirect uri must be the same you put in the first call or this will not work

This must be sent as a POST call using a tool like POSTMAN or curl.

The response will be an access token in json format.


Authorization Code
The same steps apply from above except now you use the Hubitat cloud url from below:


You will be asked to sign in:

And then asked to choose a hub:

And then to configure:

And given a code:

Access Token
Build your POST url for Postman or Curl:


The redirect uri must be the same you put in the first call or this will not work

You now have a valid oauth token which can be used to access your app mappings :grin:

See @chuck.schwer's post below on getting the app endpoints from the cloud.

As of right now, these tokens must be passed using an "Authorization: Bearer :token:" header and not using an access_token=:token: according to @chuck.schwer's post below

Retrieving Endpoints

You can retrieve endpoints using the following url structures below:



You must pass the token using an authorization header in the call:

Authorization: Bearer token


There is one more endpoint that comes in handy. that is /apps/api/endpoints you can send a request to that endpoint with your bearer token and it will tell you the endpoint to use to call the app :

1 Like

Also, for the call to /oauth/token, "hubUID" param does not need to be passed. it is not used in that particular endpoint.

Thanks! I've updated the post. I had that param come back from my ifttt flow inspection, but it might have been an artifact of my hub selection.

@chuck.schwer I just noticed that if you already created an accessToken using createAccessToken in the app, the new auth tokens generated with this method do not work and return an <error>invalid_token</error> oauth error. Can this be changed so that the new tokens allow access to the app?

i swapped multiple notes with a member of the staff to gather this info in parts, so it is awesome that you summarized it so beautifully here. Thanks so much.

1 Like

We currently treat access tokens and bearer tokens differently. We did have a discussion about treating bearer tokens the same as access tokens but it has not been implemented. So currently you have to pass access tokens in the url as a parameter and a bearer token in the headers as an Authorization header.

You can use both of them for the same app but the way to create them is different.

1 Like

Is there a way to get the endpoint of the app using the local oauth service on the hub? Mostly just for the app id since you have to know the ip of the hub to start with.

it is the same, /apps/api/endpoints

http://<hub ip>/apps/api/endpoints

and pass the Bearer token in the Authorization header

1 Like

Thanks! I tried it before posting but just realized I misspelled something in the url. I'll add it to the post.

The local OAUTH flow version stopped working for me after I updated my hub to 2.0. Anyone else having this issue?

I never tried it prior to 2.0, but it's currently not working for me either. After getting the token and executing:

curl -H "Authorization: Bearer <token>"

The response is simply: []

In case anyone stumbles upon this old thread, this problem has been fixed some time ago.


The problem that @jp0550 raised back in August of 2018 still seems to exist:

At least, I'm having the same issue/symptom. I'm working on getting my Ecobee Suite ported over once and for all, but even though the initial login returns the correct information (the same state variable I sent AND a valid authorization code for api.ecobee.com), I ALWAYS get this same invalid_token error.

Is there some trick to getting this past the Hubitat OAuth guardian? I've deleted reset my keys/secrets on both sides to no avail...it seems since the first few attempts I made failed, I can never get cloud.hubitat.com to send the data to my actual application callback...


It appears that api.Ecobee.com isn’t returning the provided access_token on its response to my initial authorization call - the error says invalid_token, with the word ‘null’. If I add “&access_token=“ to theURL in a browser, it proceeds further, only to return an error 500.

All this works from SmartThings, but I know the process is a little different for Hubitat. I just don’t know how to coerce the expected response out of Ecobee From the Hubitat platform.

Any help/suggestions are welcomed.

You might want to get in touch with @mattw ... he ported your Ecobee Suite (v1.4?, but not the helpers, I think) early last year. I'm using that version with HE at one location; it's been working fine for almost four months now.

... looks like a change to PIN authentication ...

I would prefer to avoid the Pin authentication route if at all possible - I prefer not to maintain the two versions using different authentication methods.

1 Like