Example using new SmartThings Cloud API!

Does this holder have to be managed/hosted by us?

Take ecobee for example, after a user authenticates access to a 3rd party, they automatically add a holder created & managed by them to My Apps. This allows the user to revoke access to that 3rd party at anytime. It sounds similar to your SmartApp approach, but simpler for us developers.

It doesn’t take very much. For PubNub it’s just a HTTP GET request that blocks until there is a change. There’s a little bit more code for my SSE client but there isn’t a whole lot there either.

I thought maybe that could be done without a SmartApp. I’m just not used to having to host web services for my API integrations.


So the SmartApp “holder” is a data entry with all the things we have talked about about as for custom code if you are doing a subscription then there is a URL or Lambda we call into. So we push into you not you open a firehose.

And again these are what is available in preview today. You have to have a smartapp which is pretty lightweight I think (Please try with what you can in the APIs right now) the APIs exposed are focused on ST pushing to the integration not the case where you open a stream.


Super discussion, Jeff, thank-you.

Take ActionTiles for example, though (I guess it is very similar to Home Remote’s use case…).

Every active dashboard (Panel) needs to receive a constant stream of updates from SmartThings for each Tile that is subscribed to a device. I’m not highly technical, so I don’t know offhand all the complexities…

  • But does the API support this now without an intermediary server or lamda?

  • Can a web client offer callback hooks with dynamic addresses and/or open sockets (how many)?

  • Offhand, without an intermediary, it sounds like the client would have to receive (and respond?) to lots of webhook callbacks, including Ping, or the smartapp would be taken offline?

  • Since a dashboard isn’t always running or may be offline, it sounds like bypassing a server isn’t possible?

  • If we use an arbitrary intermediate cloud service or database to receive incoming Events, this will only work if the callback messages from the smartapp are tailored for that service. But this isn’t possible in the API - right? The API requires us to accept the specific REST-API formatted authentication and JSON that you specify, and thus we would need to provide lamdas or another intermediary server to transcode and forward the incoming?

  • If I’m correct, are there plans to remove the restriction / overhead of the previous bullet? Legacy SmartApps can describe and issue (nearly) any custom outbound and inbound REST-API over http. That’s the power of having actual programming language and execution of Groovy code in the SmartThings Cloud, right?

Let me answer this and see if I got it right. @beckje01, please correct me if I’m wrong.

Yes, if you are willing to poll for data. It is not possible to consume a live stream, there’s no support for web sockets.




Correct. A lambda is the right tool for such transcoding.

No, there are no plans.

The new API is just like Smart Apps without the smarts. It provides event data to a lambda or HTTP endpoint of your choice and then you are on your own.

1 Like

I don’t see a subscribe to events option in the API. Without an event subscription, how are we supposed to keep track of everything on ST?


1 Like

Are you just looking at the example app or the new docs?

Also of interest, for those asking about subscriptions and webhook SmartApps: Example WebHook SmartApp Source Code - New APIs!


Thanks @tgauchat @beckje01. I will dig deeper in the SmartApps

cannot use this… any updated documentation… the atom ide page is blank…

Now, we just need a PyPi package for integration with Home Assistant :slight_smile:

1 Like

In the ST groovy docs there is a section titled writing your first smartapp. Its very basic and explains it well. Would be nice if someone would do something similar with the new api. For us beginners.


@Jim do you have any additional documentation on the OAuth flow with the new API? I noticed that in your Example Webhook SmartApp - New APIs the configuration/installation of the SmartApp was initiated from the SmartThings Mobile App, but I’m curious what the installation flow would be like from the web approach?

In the Configuration documentation, the diagram indicates that the configuration can be initiated from web or mobile:

In the Authorization and Permissions documentation, there was a reference to the https://auth-global.api.smartthings.com/oauth/token endpoint with respect to refresh tokens, but I couldn’t find any docs about initiating the OAuth flow from the web.

In the legacy groovy SmartApp approach, we would have initiated the request at /oauth/authorize specifying response_type=code and a few other parameters to get things kicked off.

@joshua_lyon oauth_in documentation/implementation still being worked on. Right now you can kick things off using a personal access token and an Oauth Token is sent back with each phase of configuration/install.

You can see more about oAuth here


Personal access tokens are useful for pretty much everything but the installed app and it’s subscriptions/schedules.

I am working on a node version of my energy monitor app that will show this flow.

Thanks, Jody. While the personal access token is great for testing a personal implementation, I’m looking for a more traditional OAuth flow where a user of the third-party app would initiate the OAuth flow directly from the third party app without having to get a manual token.

eg. The Authorization Code flow as used in the groovy Web Services SmartApp approach.


Been playing around with this new API and I have a few questions that perhaps the readers of this thread can answer. My goal is a rudimentary web version of the ST app, where everything happens on the client side (angular in the browser). Basic device info is fine, and I have pretty html per device showing name, hub-name, group-name, and how much battery is left if battery-powered etc. But the capabilities/status/actions are a bit more tricky. For example here is the capabilities list of my presence dongle:


and the corresponding status:


A good visualisation of this device would be to display “presence” as the primary value and perhaps “signalStrength” as secondary value. And there should be a “beep” button as that action is hiding behind the “tone” capability, but the similar “sensor” and “actuator” capabilities are just tags. But I don’t understand how I can get to that knowledge without hard coding lots and lots of information from the docs. There does not appear to be API calls for this at all, unless I’ve completely missed a vital part of the new docs. Trusting the order of the object inside “main” seems a bit dodgy, and it does not solve the actions.

To look for additional info, I ripped the SmartThings CLI out of the MacOS SDK blob and installed it on my Linux-box. It had quite a few additional API calls to a different Samsung web service for more OIC/OCF type info(*) but nothing that helped me with this. However the cli did have a number of files with device type asset info in a format I perhaps could import, but strangely enough not a complete set. Button was missing for example.

Bright ideas anyone?

*) Sample output:

$ /home/ok/cli/st describe device-status -i --resource-model --resource /st//capability/temperatureMeasurement/0
“rt”: [
“temperature”: 19.7,
“id”: “0”,
“units”: “C”,
“if”: [

1 Like

8 posts were merged into an existing topic: I’m perplex for the new SmartThings / SamsungConnect thing

This is my take on this whole issue:

  1. the problem … Smartthings servers often seem to become overloaded and events and other things stop working… Just look at all the outages. The current model seems unsustainable as usage keeps growing.

  2. the solution … This… New firmware, new api, require devices to offload the processing to servers other than smartthings servers to reduce the load.

  3. So If I understand correctly new device types like for ecobee, honeywell etc. will require web based processing on THEIR own servers to be compatible with smartthings in the future.

This brings up many problems… If the company is big enough they may do it. But now we have no single point of control and there will be finger pointing when there are outages.

Also, many companies are too small or I believe will not set up their own server farm and maintain it just to have smartthings compatibility. I cannot see qubino, aeon, eversource, etc settings up and maintaining servers just to support smartthings. I believe this will cause future incompatibilities with many currently supported devices.

I understand where this is coming from but don’t think it is the best solution…

On my side I do have a server or two I can use. I have a mail/dns server with public ip… I would like to see some conversion of existing devices types and smart apps going to your own server, this would be nice and would run locally instead of in the cloud and would work even if wider internet is down. At least if the server is on your local net. Probably will never see this however.

I can see a bidding war as in cable TV, where Honeywell wants hub companies to bid for access, if they say no, no service. What I see is another Pay to play system.

3 that is true for cloud connected devices that are already talking to a cloud system. But someone has to setup the integrations it may not always be the device manufacturer.

Other devices such as hub connected aren’t integrated via this api you can control them via the api but they don’t talk directly to this.

Automations smartapps etc are in the case where they need to run somewhere. Solutions like lambda will hopefully make these very approachable.