Jump to content

IFTTT url not just for IFTTT


apostolakisl

Recommended Posts

Upon doing my first IFTTT to ISY command via portal, I realized that this is just a POST command and has nothing special relating to IFTTT.  I have since used several other methods of sending a portal generated POST command, including sending a POST from ISY network module to another ISY.  It all works.  In short, the IFTTT label in the portal could have its title broadened such that it is clear that it simply generates a POST that is able to be implemented by anything that can do POST.  It is a bit quicker and easier to use the portal to create the POST command as compared to using REST and looking up all the various REST commands and values.  It is basically a "gui" way to make a REST.  REST does have more features, but if what you are doing doesn't need them, it is quicker and easier to generate a POST using the IFTTT section of portal.

Link to comment
Thanks for the suggestion. I made the changes in dev, this will be in production Sunday.
Benoit


Awesome! Thank you.

If we are making requests, is it on the roadmap to support more than one Key? (With a key name tag)...

The use case is more than one system. If I share a key with IFTTT and another cloud service - best practice is I share different keys. That way if one service gets compromised I must only revoke that one key...

Thanks!
Link to comment
51 minutes ago, MWareman said:

Awesome! Thank you.

If we are making requests, is it on the roadmap to support more than one Key? (With a key name tag)...

The use case is more than one system. If I share a key with IFTTT and another cloud service - best practice is I share different keys. That way if one service gets compromised I must only revoke that one key...

Thanks!

 

This is not currently in the roadmap. So far, the intent was for IFTTT, and renaming things were a small change.

For sure, it's a best practice to use different keys for different services, but how many users would use 2+ services with this?

Benoit

Link to comment

IFTTT 'alternatives' I can find quickly are:

Stringify
Automate.io
Microsoft Flow
Zapier
Pipes (https://www.pipes.digital/)
Workflow (IOS)
Tasker (Android)

Granted - the last two are not truly SaaS - but commonly are integrates using Webhook functionality. I know personally I use 4 of these (IFTTT, Stringify, Flow and Tasker). Currently - I route non-IFTTT requests to my ISY thru a personal Apache host (since I have a publicly trusted SSL cert) so each can use it's own key - and the Apache config adds the Authorization header for the ISY if the key matches one of the three I have assigned.

Certainly - allowing a certain number of keys to be valid (10?)  would be of benefit to me - but I'm not sure how many others would benefit (or even realize that there is a benefit) to seperate keys for each separate service or device being connected.

Michael.

Link to comment
  • 2 weeks later...
On 9/25/2018 at 5:15 PM, bmercier said:

You are absolutely correct. But if we rename it to something more generic, then someone looking to do IFTTT would not find it or think about IFTTT.

Benoit

Can you answer a question? If I login to the ISY portal, then go to IFTTT/Webhooks, then enter a name and device, then save, once saved clicking on the blue arrow box it gives you a URL. If I use this URL directly in a browser shouldn't it directly trigger the action on my ISY?

Link to comment
Can you answer a question? If I login to the ISY portal, then go to IFTTT/Webhooks, then enter a name and device, then save, once saved clicking on the blue arrow box it gives you a URL. If I use this URL directly in a browser shouldn't it directly trigger the action on my ISY?

No, because it requires a Post and the browser issues a Get. You could use a chrome extension like postman to simulate it.

Paul


Sent from my iPhone using Tapatalk
Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...