Continued use of Webhooks after the launch of the Apilio Service on IFTTT

[pebneter]

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.

[Lobe]

Dear Apilio Team,

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.

[pebneter]

Hi Lobe,

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:

1. Use IFTTTs webhooks to send your requests to IFTTT first and from there to Apilio
2. 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.

Hope this helps!

[Lobe]

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?

[pebneter]

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.

[hdsn555]

@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.

[pebneter]

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.

[hdsn555]

@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.

Thanks again for the ongoing support.

[mcm]

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.

Martin

[pebneter]

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.

Cheers
Philipp

[hdsn555]

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.

Just wanted to make you aware.

[pebneter]

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?

Thanks!
Philipp

[hdsn555]

Im using a IFTTT maker trigger to to update a boolean. I know its firing as boolean is updating, but its not adding a entry into my IOS calendar.

I’ve created another recipe on IFTTT to do the same to google calendar, and this seems to be working.

I will keep monitoring and update accordingly.

[hdsn555]

I’ve had a failed trigger this afternoon when leaving work, so my boolean failed to update to false, meaning no calendar entry.

I’ve tried to show the process flow, and what I’m using. Its actually failed at the trigger end rather than the final stage.

[pebneter]

If I understand that correct, the “blue” applet failed and you think it was not triggered at all (vs. triggered but not well received by Apilio)?

[hdsn555]

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.

[hdsn555]

@pebneter, have you had any other user report such issues?

[pebneter]

It happens from time to time, but we didn’t see an unusual number of complaints in the last weeks.