We're definitely interested in powering the internet of things and webhooks will definitely play a part of that. It remains to be seen if we need to have a generic hook channel to make that possible. I suspect there's one at some point in the future, but I think there are some better ways to address the same problems in the short term that appeal to a broader audience.
There's a big strategic risk in you guys offering web hooks: it facilitates competitors piggybacking on your event detection and building high value response services that compete directly with your own. In other words, you become a piece of costly-to-maintain middleware and others capture the real consumer value.
Good point - it seems like they take this risk into account in the design of their service in a couple of other ways too, like in the triggered actions. For example, you can't send a message to an arbitrary phone or Google Talk account, only your own personal, verified accounts. It would be super useful if you could send more customized messages to anywhere, but then you could build entire services on top of IFTTT.
That is interesting. It seems like the safest thing for them to do would be to offer all of these features (including webhooks) in a "pro" offering which has a monthly fee (probably based on number of notifications). So they treat any developer who wants webhooks as a would-be B2B customer.
I couldn't agree with this more, opening up a general API would be a great step forward for IFTTT.
I recently also wanted to add integration with IFTTT for something I am working on. However, instead of writing a blog post and putting it on HN, I contacted IFTTT. They responded very quickly and were interested in helping me add my own channel if my project became a product. While this may not be as easy as providing open webhooks, I think it's a viable alternative which better fits their model of being focused on the end user, not developers.
IFTTT seems to be appealing to the non-developer "configurator" person quite well, so maybe they don't want to complicate things by adding something so technical. I would guess you're feature request is not in the favorable half of the 80/20 equation for them as a business
Could be. That was what my 2nd-to-last paragraph was about. I just think that opening up that output channel to let developers run free with event data will produce some very interesting and creative uses that perhaps IFTTT hadn't considered and let people create one-off solutions for services that IFTTT doesn't yet support (such as my need last night, which I solved (sadly) with yet another Twitter poller).
Your post should have then been "IFTTT should cater to developers" not "IFTTT needs webhooks." IFTTT's entire thesis is that non-developers should be able to 'program' computers. Just because you want webhooks and they would be cool doesn't mean IFTTT should work on features that go against the entire premise of their product -- and if you think they should, this is the primary argument you should be making, not if they should be adding feature X or Y. Surely if IFTTT's target market shifted from the general public to developers, there would be many things developers would want, and webhooks is only one of them.
Absolutely agree on this one with you. We are working on similar product http://elastic.io and it's clear that in this business (IFTTT, Zapier, elastic.io, FoxWeave.com, etc) you need to work on two customers - business customers who pay and developers who are platform multipliers. That's the reason Zapier and IFTTT are trying to open up. Important is however business users (who pay) do not need 'developers' view on things, they don't need the 'flexibility' and complexity that developers needed, so essentially it's two different products. Think AppStore/App - Xcode.
I think the "IFTTT is aimed at non-developers" argument is just dumb. Add a webhook channel, and people who don't know what webhooks are will just ignore it, the same way they ignore all the other channels for things they don't use. Noone is going to be more confused by the webhooks channel than they are already confused by the weemo channel.
Put a [for web developers] tag on it if you must, but a man shouldn't be denied steak just because a baby can't chew it.
We are a small, young startup and we have to be very particular about the things that we focus on. It's really hard to say "no" or "not now" sometimes. When I started one of the first things I thought for sure I would push for was a webhook channel. As a developer I want it myself. As I become more familiar with the people who use IFTTT I don't think it's the right thing to do for them right now. This doesn't preclude us from doing it in the future, but I think there are some better ways to solve the same problems that will cater more to the audience who has identified with the service.
Bingo. Right now I don't find IFTTT very useful because the pre-made options don't fit my use-cases very well, but if I had the flexibility to do what I pleased with the data, I would be telling everyone I know about it.
I was interested in what webhooks are, but there was no link in the article. Aha! I thought to myself, I'll look it up on the internet, and behold there was webhooks.org, which I assume is its home. Going there I find no description of what it is, a broken link to the blog, and a wiki that does not exist. So I guess it's not ready for primetime?
Webhooks are very common for server-to-server communication and have been in use for several years (though they only really took off in the last couple). They are ready for primetime and there are lots of best-practices in the industry around how to implement and use webhooks.
They also go by other names such as: PubSubHubBub (PSHB), real-time API, push API, web callbacks... Basically it is just a URL endpoint that accepts POST requests with form data or JSON body payloads that come from server-generated events from other systems.
Some geek-focused services allow you to configure a webhook that will be triggered in response to [domain specific stimuli], such as a new order placed on your Shopify store.
The webhook is just the URL of a service that responds to the request in a hopefully useful way. When someone purchases my item, Shopify will post a request to the URL that contains useful information about the action.
In this manner, I can build interesting services that respond to events that happen on other websites. Providing webhooks is a pretty awesome thing to do, but it's not useful for non-developers in 2012.
It's a way to link, or "hook" to a web based service. You provide a URL where you want to receive event information, and when an event happens the server will HTTP POST the relevant information to the URL. This way, you don't have to constantly poll the service asking "did an event happen yet?"; the server will notify you automatically.
Hi, we are building something similar. We had a Kickstarter a few months back that did not reach our funding goal, but we are still forging ahead. http://www.kickstarter.com/projects/daisyworks/internet-your... -- it involves connecting hardware / arduino like sensors / controls to an IFTTT-like system.
Thing is...there are two of us building this part-time with day jobs / families. We have a really good start, but we really lack the time / resources to take it to the next level. If you are interested in this kind of thing, please drop me a note at davis@daisyworks.com -- I would love to recruit some more passionate people to get involved and make it into what you want it to be.
I love webhooks - they provide a neat portable layer between services and devices.
Currently I have Growl set up on my desktop computer and run a number of desktop programs that talk to it. I have Growl set up to ping Prowl (previously Notifo, RIP), which in turn does a push notification to my iPhone.
Things like getting an email directly to me, or having something fail my continuous integration build system, or even my son logging onto our home computer hit my iPhone, and it's so damn easy to put together.
I was frustrated with the limitations of IFTTT - I still rely on it for a few things, but just running a simple .net program on my desktop computer that is on all the time gets me 90% of the way there. (Most of my use-cases are "if x happens, I want to know about it", the esoteric [to me] scenarios like saving every gmail to my dropbox or something are not interesting to me).
Obviously it's a hack but it wouldn't be that hard to set up an IFTTT email alert to a dedicated account, parse the email for a specified code you set when creating the alert and then do whatever you wanted...
We're definitely interested in powering the internet of things and webhooks will definitely play a part of that. It remains to be seen if we need to have a generic hook channel to make that possible. I suspect there's one at some point in the future, but I think there are some better ways to address the same problems in the short term that appeal to a broader audience.
As far as getting developers on board goes: http://techcrunch.com/2012/07/24/ifttt-adds-box-and-plans-ne...
And I can confirm that there is indeed a list of channels we want to build and that a webhook channel is on it.