I got my Homey Pro 2026 today and have been playing around with it a bit now. Basically it’s a really nice system, but I’m very surprised there’s no way to block webhooks originating through the cloud-connection? Not even a way to add a bearer token or similar. Anyone, anywhere in the world could “access” my Homey Pro through https://webhook.homey.app/[homey-id]/ and get an “OK” back. This shouldn’t be possible without some kind of token/authentication. Worse even is that only homey-id:s that exists replies with an “OK”. If the id does not exist you’ll get an error saying this homey id doesn’t exist. Even if the homey-id is some kind of UUID with lots of bits, IF someone get hold of it, you’ll have to remove everything and create a new id. You really need to implement some kind of bearer token to access homeys through the cloud, and fix so you can’t check if a homey-id exists or not by the reply from webhook.homey.app.
Webhooks are meant to be used that way, since many services where you can enter them don’t allow authentication to be set.
This is also the reason why you should keep your Homey CloudID private (don’t share it).
Well at least in many other systems using webooks you can use white-listing of ip-addresses. So what are people using webhooks for? I was going to trigger a webhook from a local server connected to an ANPR-camera to open my garage door, based on some other logic too (not only licens plate), but I would feel a lot better if that webhook only could be triggered locally.
I use it with MacroDroid using the webhook.homey.app/cloudid/battery?tag=[batterylevel] every time my phone battery level changes so I can turn a light red when my phone needs charging. I also use it with my tablet to send a notification to my phone when the tablet is low on battery.
You could have searched for local webhook 
where 192.168.12.34 represents your Homey’s IP address
There should be a tag and a token. What if I want the tag to be some input data? Also the token would be stored inside the flow. All tokens should have a special section in the app so it’s easy to get an overview and change the tokens easily when needed.
It might be possible to build an app for something like that, using API endpoints with query parameters. You can learn more about building apps here:
Or you can request an app here:
That’s just an alternative way of triggering, it doesn’t block the cloud-based entry point.
It’s not, it’s a MongoDB ObjectID. Which means it encodes various information, like a timestamp of when it was created. ObjectID’s were never meant to be secure.
I think the best way to secure the Webhooks is to add a SSO service (either locally or in the cloud via Auth0 or Cognito or Google) that can generate an access token for you. You send that access token along as a tag to your Webhooks. In your flow, you can then use the logic card “make [method] request to [url] with [headers] headers and [body] body” card to relay the request to a separate server where you can verify the access token. I don’t think there’s a way to use a Crypto library inside a homey script to verify it locally, is there?
You might also be able to obtain a bearer token from Homey, send that one along, and use the Homey API itself to verify that token. But bearer tokens are officially not meant to be used that way. And at this point, it also starts to become clear what the difference is between Webhooks and API’s. Webhooks are essentially a way to implement ultra fast event based triggers to keep systems up to date. Like others have said before, they are meant to be public. You can use them to relay information between systems including access tokens. If you really want a secure way to extract or manipulate data directly, you should actually use the api for that.
If you want a webhook that can be used only locally, the ‘Micro web server’ app supports that. Web calls work only via the local network using the same subnet. To activate a flow, you need a ‘Web trigger … was received’ card to start the flow.
I use the feature a lot and it works well.
Andy
Thanks, that would probably be what I’m looking for.
True, but it doesn’t send the Homey ID to internet, if I understand the functionality correctly.
But whole you mentioned it, it should be possible to disable the cloud-based webhooks all in all.
The way it currently works, you can add a token, or passphrase to either the event or tag.
Preferrably to the event, while the tag part is optional.
You can use the tag part for anything; I might have used an unclear phrase as placeholder.
You can also keep the Homey ID private. I recommend not sharing it, as pairing view HTML files are also not protected. This means that if you know the IDs of the custom pairing views, you can create a script to enumerate which apps are installed on the Homey. Some apps also don’t protect their API endpoints, which means you might be able to view content from those.
