Hi @michaelbierman,
yes, we definitely want to extend the REST API. We launched with this very light version to see if there is a demand for an offer like it. And since we want to move away from the old web hooks the REST API becomes even more important.
We canāt publish a roadmap for the API just yet.
I would also like to cast a vote for getting numeric values.
I think this approach ā indefinitely asynchronous multi-platform variable passing ā has been taken to its logical conclusion by Microsoft Azure Queue service.
I just wish Apilio allowed easier in/out access to Variables using GET or POST requests, as you so often see mentioned in this Forum threads. People running home automation systems, not all of which are interoperable, have come to rely on MQTT and other means of syncing jobs and sharing device settingsā¦
ā¦Apilio really could own that market if you went beyond the IFTTT-only approach (too fiddly to set up for this use case) and offered Boolean, Numeric & String variable stores, with push/pull/timestamp action options over HTTP.
If I can do it with a Google Apps Script in my underwear, I know you guys can nail it!!
Hi @LibraSun,
Thanks for your feedback! A full REST API is on my personal wish list since a long time
Have you had a look at the current API that was mentioned before in this thread? If we extended that to cover all actions, would that meet your requirements or would you need more than that?
Awesome hearing from you, and really appreciate all your efforts on customersā behalf.
Yes, a full REST API with the ability to push/pull NUMERIC, STRING, BOOLEAN and heck, why not JSON objects? After all, these are easily passed via URL (GET for simplicity and POST for those seeking extra security) and have become the gold standard for truly asynchronous variable storage and retrieval for home automation needs.
Use case: Say you have two or more home controllers in different locations, perhaps even with different time zones. Your API would allow one system to effectively communicate its various states (Mode, Temp, Alarm, etc.) to the other units through Apilio.
Itās a huge potential win, win! But not trivial for hobbyists and coders because it would require an always-on solution that can pass back unencumbered data (Google, for example, forces Apps Script modules to enshroud results either in massive HTML or a site redirect!). Trying to send the data directly would raise the spectre of having to open router ports.
Again, by offering a way to do this securely through an API, Apilio wins!
Do I understand correctly that there is no API nor any way to get say, a string variable value via IFTTT?
Similar to @LibraSunās request I am trying to use homebridge to control a device. I can turn on and off the device via IFTT. But I donāt know how to get the current status. I have a string variable in apilio but I donāt know how to retrieve the value.
You are correct - unfortunately . You can only read out Boolean variables at the moment as in the document linked.
Thank you. For this particular case I was able to work around this limitation. Iām just curious what makes other variable types challenging to enable?
Itās not a technical challenge , but to get it done properly and among a lot of other things to implement with the given team.
The Postman link has been deleted and is no longer accessible.
Hi @BenCour,
thanks for reporting it!
The documentation was offline indeed - I was not aware that postman had archived it. I republished the documentation and the link is working again: https://documenter.getpostman.com/view/7602053/S1TSZeSA
I will answer your other question on the API on the other thread.
Unfortunately, still getting the 404. Did the link change ?
Ben
No, itās the same link as before.
hmmmā¦ thatās weird. I tried to change some settings and did a re-publish. Can you access the URL now or this one here: https://explore.postman.com/api/8923/apilio-web-api-v1
I can access the description link you just posted but not the API documentation itstelf. Still getting a 404
ok. Maybe it takes a while until it is distributed to all content delivery servers or it is cached somewhere. Can you try again a bit later (or with a browser in incognito mode)?
Another input from a user: Heād like to have a URL that is usable with IFTTT webhooks:
- Would have to work with the constraints of Webhooks on IFTTT (e.g. configurability)
- Would have to respond with data that is readable by IFTTT
Hey everyone!
Good news: We launched the re-implemented webhooks feature recently
We are also planning to expand the REST API for people who are more interested in using this kind of interface. Now there are two questions for you folks:
- With the new webhooks API, are all your needs covered?
- We are thinking about implementing a authentication close to or 100% OAuth2 standard. Is that something you would welcome or do you prefer having authentication done via a relatively easy to handle static secret key?