the developer console shows service integrations that use the API now. Not sure when it was added but I was able to find why ST was messaging me about paying the upcoming monthly fee. It was an old Hubithing integration i installed 3 years ago to test. I have removed it so yippie!
The Developer Plan is currently available in the United States, Korea, Belgium, France, Germany, Italy, the Netherlands, Poland, and the United Kingdom. Availability may expand over time.
SmartThings API Plans for Developers and Businesses - Connected Services - SmartThings Developers
Yes. that appeared today. It should have been previously been visible using the CLI (smartthings apps) or in the /apps endpoint of the API.
UPDATE: It would appear that my receiving a 403 error on /smartapps may have been due to the nature of the PAT I was using, and had I used a different token I would have discovered that the new endpoint also handles Webhook apps, although the API Reference allows you to infer the contrary. I have removed the remainder of this post from view as it would be too misleading.
So, basically, if I want to directly call the API, not via CLI or AWA, I have to have a subscription? That seems to bear out as I’m getting
"error": { "code": "ForbiddenError", "message": "Not authorized",
for Postman calls that used to work.
My current best guess is that the subscription gives you access to the /smartapps endpoint of the API which is required to be able to create or update API Access apps. That’s pretty much it, if we ignore rate limits etc for the moment.
Update: It is probably less crude than that as using a different token avoids a 403 and reveals /smartapps is not exclusive to API Access apps.
The /smartapps endpoint has completely replaced the /apps endpoint in the API Reference, the Core SDK and the CLI.
The /apps endpoint has started returning 403 for me today. This means I can no longer manage my Webhook SmartApps via the API. While clearly it would be ridiculous if /apps could still manage API Access apps as it would bypass the subscription plan, this is a breaking change.
Update: It would appear my receiving a 403 on /smartapps is not the intention going forwards, but might be related to the particular PAT I was using. /smartapps returns Webhook SmartApps too.
I have not noticed any other changes in the API behaviour today, at least not on a read-only basis. I have an app that has a good poke around.
Hmm, well it’s working now for a simple GET on a device so perhaps a transient error.
So, if I understand what you are saying, any tool or service that simply pulls device information or issues commands to devices via the API should not be affected. So, things like the API Browser+ should keep working. It’s only the actual SmartApps that will require a subscription.
Yes, the target is specifically the API Access apps, also known as the API_ONLY apps, the OAuth-In apps, or more vaguely the OAuth2 app. More specifically it is the ability to create and update the API objects that define them that requires the subscription.
However we shouldn’t forget that when the long lasting PATs were scrapped, a popular workaround was to create largely headless apps just to get renewable tokens to use instead of PATs. Anyone who took that path would have created API Access apps.
I would also suggest that we haven’t heard the last when it comes to restrictions on PATs. When they are mentioned things get very vague very quickly. So those community created tools that continue to use PATs should be fine as long as they steer clear of working with API Access apps, but I wouldn’t want to get too cosy with them.
There is also the issue of automations. Until recently Webhook and Lambda apps were the recommended solution for advanced automations that Rules could not handle, and before that they were also suggested for cloud devices. They weren’t really publicised but their basic usage was well documented. All of a sudden they seem to be disappearing without comment. What is the recommendation for advanced automations now? It is API Access apps.
Fyi
I guess times are tough even for samsung ??
Perfect timing - one more device and my migration to Home Assistant is complete. It was an interesting 11 years folks!
It seems that /smartapps returning a 403 could be related to my use of a long-lived PAT. Creating a PAT is far too tedious, but using my CLI token instead is certainly successful and also returns my Webhook SmartApps. I have therefore tweaked a couple of posts to either strike out or remove misleading comments.