I have created an App that I today uses regular API GET in to get data from the device that the App are controlling.
But I want to start using WebHook instead to reduce the number of API GET request towards the suppliers API service.
This is the first time I ever work with WEBHOOK and don’t fully understand the concept. If I on the Developer page create a WEBHOOK to be used and implements that in my App, will it be that webhook that all users of my App will use? If so, how does it determine that the user gets their data and not someone else data as they are using the same WEBHOOK?
Or must every user of my app create their own WEBHOOK and put in some configuration values in my App for it?
But if I understand correctly, I use just one WEBHOOK in my App but also include the users HomeyID as a parameter when registering the request. This means that all users of the App will use the same WEBHOOK but their HomeyID are also registered so they will only get the data that belongs to them?
Maybe you can elaborate a little bit about how to replace a GET with a webhook?
With a GET your Homey is asking for data from some other system, using the API of that other system.
With a WebHook the remote system is asking Homey to execute a flow? Are you able to change the remote system? I just don’t get it😁
By making a webhook, you define an API for Homey.
With API GET in my App the App are “asking” the remote API for data about things in the remote API service, such as status of a device.
With in my App registering a WEBHOOK service towards the same remote API my App will instead one time ask the remote API to automatically send things like status of a device automatically when it happens in the remote API.
So instead of repeating API GET requests towards the remote API service you only do one request and tell the remote API to send you updates as soon as they happen in the remote API.
There are two types of webhooks with Homey: one has to do with flows (which @Rmb is referring to, and which isn’t the one being discussed here) and the other one is a push-type service from a remote API to Homey to update device states.
The remote API obviously has to have explicit support for webhooks before you can implement them in your app, but if it does, it’s much better than using periodic GET requests to the remote API because it will only call the webhook URL when something changed.
The API will need to support webhooks and allow you register it so it knows where to send the data. The data should also contain some information that is unique to each user and when your app registers the webhook it will need to pass in that unique information so the Athom server knows which Homey to forward it on to.
Although the documentation is pretty bad, there’s a lot of inconsistencies in there.