We are very excited that we were able to launch our native IFTTT Service at the end of October 2019.
The native integration replaces the use of IFTTT Webhooks to connect Apilio with IFTTT and comes with a couple of advantages:
Faster and less error-prone setup
Higher reliability
Better transparency to troubleshoot
To not confuse new users with two integration methods, we removed the options and information to create new connections via the IFTTT Webhooks Service for both incoming and outgoing traffic.
But of course we made sure that all existing integrations and configurations will continue to work as before and you also can still access and edit the elements.
Since we believe the mentioned advantages make a big difference, we encourage everyone to migrate to the native IFTTT Service over the next couple of weeks. We have created a guide that should help you doing it.
We also already have a backlog full of improvements and new features that we want to implement. So watch out for improvements over the next few weeks and months!
We have not a fixed date when we will discontinue support for the IFTTT Webhooks - we want to give everyone enough time for a smooth transition. But since supporting legacy features costs effort for maintenance, we aim to sunset it as soon as feasible. āQ1 2020ā is a fuzzy goal that we have in mind.
Apilio is a great service desgined for integration with ifttt. But, you have developed more than this ā¦
Please, donāt remove the option to set variables with REST call ā¦ I am integrating some others services that are calling the variables setters without ifttt.
For example: My Shelly controllers, have an action called when the switch is on and when is off. This action call an Apilio set bool . With this action i can make logics blocks in base to the switch state.
Another sample: I am using Automate, an Android App for design WorkFlows with all the android devices events. Its very powerfull, and I can set variables from this app thanks to te REST calls.
Please, donāt remove this option and show the setters links again.
we also like open APIs, and we do not intend to remove the ability to modify contents via REST api.
But the now deprecated API was for practicality reasons built for GET requests and with a simple authentication method - and weād like to remove those old methods at one point.
There are two alternatives available:
Use IFTTTs webhooks to send your requests to IFTTT first and from there to Apilio
We have made a MVP for a newly designed REST API: Apilio web API v1. If there is enough demand, weād be happy to add more methods to that API.
I understand, the REST API: Apilio web API v1 will be the replace for the request outside the ifttt.
But currently this API only allow get a value, donāt set, no?
Yes, the web API v1 is for getting a boolean value only. We could expand the methods if thereās enough demand for it.
To set a variable or trigger an evaluation via a webhook, our current assumption is that youād create a webhooks-to-Apilio applet and use the address provided by IFTTT (instead of going directly to Apilio.
@pebneter Iāve been using Apilio since July this year, and itās amazing. I switched to this after the demise of Stringify.
Iāve just noticed the new IFTTT integration and wanted to switch everything over. Which I seem to have done with success (still need to test before I delete my old webhooks applet) however one thing Iām a little saddened by is I no longer have the ability to use webhooks to trigger true/false status, which I am using for a stand-alone geofence app.
Iāve tried before to use IFTTT Geofencing, but its extremely unreliable and doesnāt fire half the time, or fires late. So I use webhooks and IOS app āLocativeā this has worked 100% of the time since switching early August. Iāve only just realised I can no longer use webhooks when trying to create a new applet to log work hours based on an at_work true/false boolean.
Please, can you consider allowing the webhooks function within an advanced tab? I have no faith in the geofencing via IFTTT, and Locative is rendered unusable on any new recipes. Please feedback.
Hi @hdsn555!
Showing the Webhooks again would be technically easy, but weād like to sunset this interface for the reasons given above.
Is the suggested alternative (use a IFTTT Webhook to pass on the data to Apilio) feasibly for you? Does the app you use also support sending POST/PUT/PATCH requests (which would be more appropriate according to the REST idea)?
We certainly want to be the most developer friendly and open home automation platform and therefore donāt want to take anything away that is much appreciated by our users.
@pebneter Iāve read through some of the guides on here and have successfully rerouted through IFTTT successfully, and learned a a few other things while doing so.
The main problem that I have is for outgoing Webhooks (Apilio -> iftttj. I have various ifttt Webhooks which are call by Apilio and other services. Without the ability to directly address these from within Apilio, and having to use the Apilio/ifttt methods means that I have to duplicate them all.
Hey @mcm,
ok, I think I understood now. I only thought about the opposite direction (World -> Apilio), but I see why using a webhook could be beneficial.
We will keep it in mind, but to be honest this is not a high priority right now, since it is probably not a very common requirement (open to be convinced it is) and there is a workaround available.
I have noticed that since migrating over to the native IFTTT service for triggering, I am seeing less reliability. This is at the IFTTT end of things, previously when using using apilio webhooks it worked every single time.
I rely on webhooks to trigger a geofence, turning on lights or logging an event to calendars etc.but Iāve arrived home to no lights several times already, or missed logs into a calendar showing up hours later.
hmmmā¦ this is worrisome. The reliability is supposed to go UP, not DOWN.
Did you make this observation for incoming information (IFTTT to Apilio) or both ways? And does it happen with only a specific service?
Correct, it seems my geofence app tried to trigger, but failed to get a response from the IFTTT server, so nothing else happened.
I have however had it fail further down the process, I.e Boolean triggered by geofence, so status set to true/false, then Apilio to IFTTT should have flowed and potentially does, but then the IFTTT to service (calendar, smart device service) fails, or is heavily delayed.
Iām not sure how to look for confirmation that after the Boolean status change that Apilio is flowing back to IFTTT, But Iām assuming it is.