Will this also affect Homey users, @Doekse ?
I can confirm that we were also notified by Samsung about the upcoming changes.
As I’ve mentioned to many other partners before, our position hasn’t changed: we simply don’t pay for API access. Our goal at Homey is to make the smart home better together, and we don’t believe charging each other fees to make integrations work is the right foundation for a partnership. We’d much rather build mutually beneficial partnerships that create value for our partners, for Homey, and most importantly, for our shared users.
At this point I can’t yet confirm exactly how we’ll handle these changes, as we’re still evaluating the different options. As soon as we know more, I’ll make sure to keep everyone updated.
I think it might be possible to build an edge driver that runs on the SmartThings hub, and can sync virtual devices from Homey to SmartThings. Then, you can use routines to link them to a “real” device to control it in Homey. I will buy the hub, i’ll see if it’s possible
But in that case, why do you charge brands €100 to publish an official app?
Where does it say that we charge our partners €100 to publish their app?
If you’re referring to the Verified Developer License, that’s not the case. Partners who are part of the Works with Homey program receive the license free of charge. The €100 fee only applies to developers who are not part of the Works with Homey partnership program.
oooooo a double standard
Not part of our exclusive club, sorry that’s 100 euros please.
It’s worth mentioning that any company can become a Works with Homey partner. It’s not an exclusive club with strict entry requirements like you’re making it out to be 
The entire purpose of the Works with Homey program is to ensure that partner products work reliably with our platform, and we handle the certification process completely free of charge.
The only scenario in which a company would actually pay for a Verified Developer License is if they wanted to publish an app to the Homey App Store and either: Didn’t reach out to us beforehand, or deliberately chose not to work with us at all.
In my entire time at Homey, I’ve never seen either of those situations happen 
The reason the Verified Developer License costs €100 is because every verified and official app goes through a thorough certification process. That testing is carried out by real people, and naturally that comes with costs.
For brands that are part of the Works with Homey program, we waive that fee because there are many other opportunities for collaboration and cross-marketing that create value for both sides. If a brand chooses not to participate in the program, those opportunities simply aren’t there, which is why the standard license fee applies.
But let’s keep the topic to what it’s about. If there are any questions about how we handle partnerships at Homey you can of course reach out or start another topic! 
Got this mail today what does this mean for the official homey app @Doekse
As the SmartThings platform expands to support over 460 million registered users, our API infrastructure requires an evolution. Starting in October 2026, we are transitioning the SmartThings API from a free model to structured, paid tiers so we can reinvest in our infrastructure and continue to provide an incredible service to support your needs.
Since you created a SmartThings API Access App utilizing OAuth, your integration will be impacted by these upcoming platform changes. These essential notifications are to keep you informed of the changes and how they will impact you.
Please note:
- No Immediate Interruption: Your current API usage will not be interrupted today. We are sharing this news early to give all users ample time to prepare.
- Free Access Through September 2026: Free API access will remain fully available throughout September 2026. New usage limits and the phase-out of free access will not begin until October 2026.
- Upgraded Experience in the Developer Center: We will launch an upgraded Developer Center for API users, including an API Usage Dashboard. This will allow you to track your current API call volume so you can understand your quota usage. These updates will make onboarding faster and API management more intuitive.
- For Commercial Partners: For partners using our API to power commercial offerings, we are rolling out dedicated commercial tiers for flexible usage needs. To ensure a seamless transition, please contact us at partners@smartthings.com.
- For Non-Commercial, Individual Developers: We remain deeply committed to our developer community. For those using our APIs for personal smart home configurations, we are introducing a dedicated $4.99-per-month paid plan starting in October 2026, specifically tailored to individual needs—more details to follow.
For more context on these updates, please read our full announcement on the SmartThings Blog.
Thank you for building with SmartThings. Our investments in the API, and this transition to a paid model, are efforts to enhance it and broaden our feature offerings for you.
Best regards,
The Samsung SmartThings Team
Asked and answered here.
Someone using a competing home automation platform is working on a fully local implementation for Samsung devices: GitHub - mbillow/localthings: Local-control Home Assistant component that authenticates to newer-firmware Samsung devices and talks over CoAP-DTLS. · GitHub
Until someone at Samsung notices it and removes this undocumented API via OTA, since this is probably unintentionally left in so it would be pretty easy to remove without any ordinary user noticing
You should use Google Home, they can’t simply kill that without a lot of backlash from users. Example:
Create a Virtual Device in Homey and choose the Kettle device type. In my case, my Smart Monitors are not natively in Google Home so I need to create a scene in SmartThings that turns them on and off. Then, install the Google Home mobile app (a Google Home device isn’t necessary). In the Google Home app, link SmartThings and Homey via + → Link apps and services → Works with Google.
You can now create automations in Google Home. Go to the Automations tab, create a new automation, tap the menu and choose “Previous household editor”, since the current editor doesn’t support starting scenes yet. You can select the starter “Virtual device turns on” and the action “Control smart home devices”. In the list of devices, scroll all the way down until you find “Set scenes”. Here, you’ll find all your SmartThings scenes. You can now trigger actions in SmartThings with the virtual device. Repeat this process until you have all scenes that you want.
Google Home is just such a core part of smart homes that Samsung can’t just remove it, if they do then many (ordinary) users will probably leave.
I’d rather not.
From my reading, the API is entirely local. I don’t think my oven can update OTA (it can’t even sychronise its clock!) in which case, there’s nothing Samsung can do about it.
Andy
Most serious manufacturers can send OTAs to the communications module. The oven firmware that handles the display panel is usually completely separate from this. Usually, manufacturers first build the appliance design and panel and only when it’s fully finished, they add the smart functionality. This usually happens via a WiFi to Serial bridge, which communicates via a serial protocol to the main board. So the main board that handles the clock and display panel does not have any network connectivity, only the communications board can connect with the network.
It’ll only work with “smart” devices that are capable of cloud communication, so theoretically, the manufacturer can push an OTA update to the device to disable the local API. Which is why, once the local communication is working, you typically block cloud access for the device in your router/firewall. That’s what I do with Tuya devices too once they are under control of Local Tuya.
Why would you do that? Tuya integration with Homey is free, no subscriptions, what do you have to lose? I myself actually do it the opposite way: blocking almost all local connections and forcing everything to use cloud servers. Because I obviously don’t want my cheap IoT devices to communicate with any device on the local network, since usually they have poor authentication on the local APIs. The only exception is the Hue Bridge, I still have to finish the cloud app for that but once that’s all working, I can fully block local communication.
Why would I need it if I have full local control?
What if Homey ever drops offline and you need to quickly control it? You can’t use the Tuya mobile app anymore. Also blocking OTA is really unsafe if there’s no real reason to block it, since your devices are vulnerable when they don’t get updates. I allow internet to all of my devices, full unrestricted internet access. The only thing I block in DNS is an expired domain that one of my devices is trying to reach sometimes, since I don’t know what it sends there and if an attacker would be able to hack it if they would claim the domain. But I don’t see a reason to block internet access to a device while its API is completely free of charge.
I can install a Local Tuya CLI tool on various machines in my network in case my Home Assistant (not Homey) ever drops offline, but that’s never happened in the many years that I’ve used it.
And still, I’d rather use an Open Source controller for my Tuya devices than a closed cloud service managed by I-don’t-know-who 
I’m also not very susceptible to FUD.
Funny though that you’re saying that Samsung could close this local access API via OTA and you don’t seem to think that that is wrong in any way. The vulnerability here is having OTA support, IMO.
