IFTTT Needs Webhooks, Stat
blog.jazzychad.net
blog.jazzychad.net
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.
Mind. Blown.
> Last night, I needed a way for a webhook to be notified each time I posted a new tweet.
Tweets can come from a variety of sources, so hooking in at the source isn't always possible or even reasonable.
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.
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.
A webhook is just a callback that notifies an arbitrary URL when an event occurs. A good explanation is here:
http://timothyfitz.wordpress.com/2009/02/09/what-webhooks-ar...
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.
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.
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.
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).