Add ability to receive POST requests to Apilio inbound webhooks functionality

Add ability to receive POST requests to Apilio inbound webhooks functionality

Today (June 19) Apilio only accepts GET requests from IFTTT and other services. Certain customers would appreciate the ability to send POST requests to Apilio.

A word on the HTTP method: Yes, currently you have to use GET. I know that this is not quite correct from a purist RESTful interpretation - actually, it should be implemented as PATCH method ( I chose GET to simplify the setup process for non-technical users (because GET might sound familiar to most).!topic/apilio/PRovworxSZk


In my opinion this is a very interesting request!!

But i think that the more important reason is the security… With the GET resquest, any person in the middle of the communication can see the request and can execute it later…

I think only accept GET resquest is a big security problem…
If apilio accepts POST request, the key can pass in the body and over a HTTPS connection the data can’t be view for a middle person.

I understand that the GET option is available to facilitate configuration, but I believe that the POST option should be given to ensure a minimum of security.

Thanks for your excellent work with apilio!!


Hi @Lobe,
we were able to integrate directly with IFTTT in the meantime and we are therefore encouraging users to migrate to that way of integrating.
We are trialing a more strict REST API that does not allow data updates via GET - you can check it out here: Apilio web API v1

But generally speaking, sending data via GET request is not as risky as many believe. Apart from the hostname, the URI and all data is in fact encrypted. A nice explanation is here: or of course directly at the source:

1 Like

The problem is that all the data at the moment of the suggestion (I don’t know how works now with the ifttt integration) navigated on the url… Any person in the middle can reproduce the request and turn on the light…

But I don’t think that differentiates GET from POST requests.
The topic of replaying requests is not trivial and there is an interesting article on Cloudflare’s blog that also touches on it:

1 Like

If you send a post request over https, the identifier of the user and the identifier of the var can send in the body of the request. This data isn’t visible for any person in the middle. The most important data is the user identifier.

1 Like

But that’s the same for a GET request. The path is not visible and any parameters are encrypted.

1 Like

I am just loving this ahem discussion chain!

Is not the same…
Get request example:

Post request example:
Body params:

In the first request (GET), the URL is completely visible so the parameters are visible and anyone in the middle, copying the URL into the browser can relaunch the request.
In the second (POST), if the request is about HTTPS, the url is visible but does not provide compromised information. The body of the petition will not be visible, so no one can reproduce the petition.

I’m sorry for my English, I didn’t expect to have to write so much … hehehe


what a shame I can only do one “thumbs up”…

:grin: Ok, @DanT. @Lobe and I stop it here. We agree to not agree :blush:


@Lobe I think that means we won! :stuck_out_tongue_winking_eye:

1 Like

Came here wondering whether it’s possible to update/retrieve stored Variables (Boolean, Numeric, String) using GET requests, instead of having to route through IFTTT.

Reading thread, I think I’m still not sure about that particular tidbit.

Can someone clarify for this wayward n00b?? Thx!

1 Like

We have a beta version of the REST API out with limited functionality to gather feedback and to see if there is demand for such a feature. The documentation is here:


The docs and sample code are nice, but don’t show users how to SET a variable using GET or POST. I’m hoping the entire mechanism can coexist with IFTTT-based methods, while still providing direct HTTPS access if users prefer.

Want frosting for this cake? Allow users to view and edit all their variables on a single Web page, since sometimes it’s helpful to have a backend “control panel”. Helps debug your workflow faster than poking around one-by-one with URL calls to see what’s what.

1 Like

Great feedback, thanks!
It currently supports only the one GET method documented, but we consider to expand depending on the user feedback. Thanks for your vote!
We are also working on improving the UI and adding new features, so stay tuned :slight_smile:


1 Like