SharePoint Webhooks -- now Generally Available!

Iron Contributor

Hello everyone,


Just wanted to announce that SharePoint Webhooks is now Generally Available. First announced in preview in September, Webhooks is now ready for developers to use against production sites.


Webhooks are based on industry standard patterns around how services fire notifications that developers can intercept and react to. In particular, within SharePoint we've added support for webhooks against SharePoint list data, including events like Item Added, Updated, and Deleted. A developer could then choose to kick off a process, or programmatically update a document, or fire off a tailored notification to users using information you can get from webhooks. You can find an end-to-end overview and "getting started" with webhooks via our documentation.  Look forward to seeing what you all build with these!


-- Mike Ammerlaan, Office Ecosystem Marketing team

13 Replies
Cool great news!


Is there an estimated time of bringing this one to SP2016?

Hi Mike,


Is there any option to implement webhooks on Office Videos?


Currently in our scenario, we have written an timerjob which has some Office Video Portal API logic to check if any new videos are added to the portal and getting summary of that data on daily basis.


My thought is to have an webhook and notify respective teams when some video is added to the portal. What would be recommended approach for this?



We’re considering on-prem SP2016 support for webhooks, but don’t have a date for that to share at this point. 

Thanks for sharing...

Hi Mike,


When would it be able for you to share a date for on-prem SP2016 support?




Hi Srinivas, sorry for the delay in response.  We don't have a dedicated set of webhooks for Office Videos as yet.. we definitely take your feedback that this would be a very useful thing!

Postman always gives bad request, not sure what wrong I have done in step1 of Adding Azure Application. Can someone help?

I really haven't gotten a clear picture on the Webhooks vs. Event Reciever story.  At first I thought i would be that Envent revcievers are not allowed in SPOnline.  But some of my searchs result a "remote reciever".  Not really sure what that is ...but.....well you get the jist.


Any clarity?  How about a link to an article?  I'll take anything.

Event receivers have been part of SharePoint for years. They enable you to run code on the server in response to an event in a list/library. If you know how to create SharePoint farm solutions, they are easy to implement, but because they run on the server a poorly written event receiver can cause major issues, and as such are not allowed in O365.


Remote Event Receivers were the solution to the above. In this model, SharePoint calls a WFC endpoint for a specified event in a list/library. This solves the issue re running code on the server. So, create a WCF service, host it on some server, and configure sharepoint to call it for a specified event (this last step is done by deploying a SharePoint app AKA add-in)


Web hooks are the newest version of the above. Like remote event receivers, SharePoint is simply doing a call to another service for a specified event on a list/library. However, instead of a WCF service, the web hook is simply making an HTTP call (so, a POST to a URL). One option for creating a webhook is an Azure function:  create a function based on an HTTP trigger, then register that function with SharePoint. Non SharePoint devs will like this, as they don't need to know as much about SharePoint to get this up and running. Again, it uses HTTP calls instead of WCF, which is another plus. Also, since other services use web hooks, it means that devs can build events for many services using one set of technologies, instead of having to learn a different system for each service. For example, wordpress supports web hooks, so a developer could  support events in sharepoint and wordpress by creating azure functions, and wouldn't have to learn the esoterics of SharePoint add-ins.


Any future development should probably look at using web hooks instead of remote event receivers.

Thx for the comparison. Is there any reason to switch to using web hooks (besides being nice to future developers :) )? We are currently using remove event receivers, deployed using SP Add in. Is there for example any improvement in performance? Avoiding the use of SP Add-In is, as far as I can see, the biggest plus for using web hooks. 

One detail that might be useful is that web hooks have an automatic retry mechanism. According to the docs linked to above: "If an event occurs in SharePoint and your service endpoint is not reachable (e.g., due to maintenance) SharePoint will retry sending the notification. SharePoint performs a retry of 5 times with a 5 minute wait time between the attempts". To contrast, there is no queue and no retry mechanism for remote event receivers.