The ASP.NET Web API has proven to be a vital part of Web applications since Microsoft introduced it in ASP.NET 4.0 back in 2012. It will receive a major overhaul in ASP.NET 5, when it will merge wtih ASP.NET MVC to provide a single, unified programming model. And in early September, Microsoft announced a new feature built on the Web API, called ASP.NET WebHooks. This really isn’t a new technology as such, but it provides an easy way to implement a common event pattern.

Microsoft describes webhooks like this:

WebHooks is a lightweight HTTP pattern providing a simple pub/sub model for wiring together Web APIs and SaaS services. When an event happens in a service, a notification is sent in the form of an HTTP POST request to registered subscribers. The POST request contains information about the event which makes it possible for the receiver to act accordingly.

Webhooks is nothing new. Jeff Lindsay reportedly coined the term in 2007 in his blog post, Web hooks to revolutionize the web, where he explained the concept’s roots in Unix. A simpler way to describe a webhook is as a user-defined HTTP callback, and many Web services implement them already. Even WordPress and other CMS tools have support for them, so it is high time that ASP.NET adds direct support for them.

By the way, Microsoft seems to insist on writing it WebHooks while most of the rest of the world writes it webhooks. You say tomato, etc. I’ll go with the rest of the world, except when I’m explicitly referring to Microsoft’s technology.

You could certainly wire up your own support for webhooks in the current version of the ASP.NET Web API, but ASP.NET WebHooks will include explicit support that will make it much easier to both send and receive webhooks in an application. On the receiving side, it provides a common model you can use to receive and process webhooks, with built-in support for Dropbox, GitHub, Instagram, MailChimp, PayPal, Pusher, Salesforce, Slack, Stripe, Trello, and WordPress. But you can build your own support for any other service you want to use using the support for custom webhooks. On the sending side, ASP.NET WebHooks has support for creating, managing, and storing webhooks, as well as sending event notifications to whoever subscribes to them, using whatever events you care to define.

Here’s a summary of how a webhook flow goes, according to Microsoft:

  1. The webhook sender exposes events that a client can subscribe to. The events describe observable changes to the system.

  2. The webhook receiver subscribes by registering a webhook, which consists of four parts:

    • A URI for where the event notification should be posted in the form of an HTTP POST request;

    • A set of filters describing the particular events for which the WebHook should be fired;

    • A secret key which is used to sign the HTTP POST request;

    • Additional data which is to be included in the HTTP POST request, such as additional HTTP header fields or properties included in the HTTP POST request body

  3. Once an event happens, the matching WebHook registrations are found and HTTP POST requests are submitted.

The ASP.NET WebHooks preview targets ASP.NET Web API 2 and ASP.NET MVC 5. You can find the open source software on GitHub, or you can install it as NuGet packages. For sending webhooks, you’ll need at least the Microsoft.AspNet.WebHooks.Custom package. Then, depending on how you’re using webhooks, you may need these additional packages:

You can find the appropriate packages for the built-in and custom receivers at the following link, which is a custom search:

ASP.NET WebHooks is a new technology fresh into its preview release, but it looks to me like a no-brainer for any application that needs to hook into these kinds of HTTP callbacks. Kudos to the ASP.NET team for recognizing the need to implement a common pattern and making it easy to implement in Web development projects. They are the rock stars of Microsoft product teams these days!


There has been a fair bit of buzz about WebHooks in the month or so since Microsoft released the preview. Here are a few Web pages and blog posts that I’ve found useful while trying to get my head around this new feature.