Allow GET requests to trigger webhooks

I would like to be able to trigger a webhooks by opening a bookmark. Such as:

https://homeassistant.example.com/api/webhook/somelonghexstring

But since you can’t call a HA webhook just by opening up a URL, I’m forced to use a workaround like using IFTTT. The following will accept a GET request which then calls my HA webhook above with POST.

https://maker.ifttt.com/trigger/call_my_ha_webhook_with_post/with/key/anotherlongexstring

It would be nice to eliminate IFTTT from the equation.

Sounds like it could be useful to communucate with devices that don’t support MQTT - how would authentication be handled?

The same way one calls a webhook for IFTTT. Use an authentication token and HTTPS.

Right now I literally have IFTTT call my HA hook because IFTTT can make a receive a webhook request via GET and make a call with POST. If HA could accept a GET request, I can bypass IFTTT altogether.

1 Like

You may be able to use NodeRED to replace IFTTT I think, if you use the websocket node for Homeassistant then NodeRED is able to send the commands.

Here’s an HTTP endpoint example:

https://cookbook.nodered.org/http/create-an-http-endpoint

I suppose another workaround is nice, but was hoping the devs could bake in get requests. Not sure how hard that would be.

Yep I agree it would be nice to have without any extra stuff running - I’d also like this feature. In fact it would allow me to use PiCorePlayer to trigger HA stuff with only some shellscript on PCP as it doesn’t do MQTT :slight_smile:

Rock the Vote ^

Bump da bump!

BUMP, just ran into this with iBrew which implements it’s triggers via get requests :frowning:

The SHELLY devices also use GET-method for their ACTIONS.

I am using ShellyForHASS as add-on for SHELLY Devices - but I have massive problems with the “physical Switch state”, which is very much delayed , even when using CoAP (FW1.8.3, ShellyForHass 0.2.0).

As such I would like to use the SHELLY-ACTIONS (which call webhooks via GET Method) to send the physical-switch-state to HA.

I did try “HTTP IN”-nodes in Node-Red - but this did not work either - as I had to authenticate.

It would be GREAT if HA would accept GET webhooks!

2 Likes

bumpity bump

Mobotix “IP Notify Profiles” are also only able to send HTTP GET requests, so +1 for GET!

Yeah, one more for Shelly-actions which do GET and not POST, therefore cannot be used :frowning:

The HA team made a big fuss about more native integration between shelly and HA, so this is then the next missing piece! easy actions based on button presses or other events on the shelly to trigger stuff in HA, that can be done by allowing GET requests on webhooks, or by them interfacing with Shelly to make something else work, either way, use that relationship and make this first class!

+1 for the GET webhooks please

1 Like

Another +1 for supporting HTTP GET for webhooks. I just bought a new RPi, setup HA & subscribed to HA cloud for this exact scenario (e.g. triggering via the Shelly I/O URL actions). Dissapointed :frowning:

I’ve just got a smartwatch and has the option of sending http commands from configured buttons.
Would love to be able to control certain group switches from it.

At the moment I’m using a sonoff rf keyfob for alarm/motion trigger switches.
Would be great if I could send an http get to trigger a group turn on/off for example.

+1 for GET here - would be awesome with my new Kronaby hybrid watch

If get poses extra security risk, it may be only allowed when switched on with a specific yaml key.

+1 for GET…

I made a work around of creating a GET url through IFTTT with Webhooks, then connecting it to the HA generated POST URL with a second webhook. But the latency is like 3-4 seconds due the use of the cloud. Not optimal, but it is working for now until this gets baked in to HA.