What are webhooks, and why should you be using them? A webhook is a way to deliver real-time data to applications. Unlike traditional APIs where you need to poll for data frequently in order to get quasi real-time information, webhooks send data immediately.
You can think about webhooks like push notifications on your mobile phone. Rather than burning up the battery on your phone fetching information (polling) from applications to get updates, push notifications (webhooks) automatically send data based on event triggers. And just like push notifications, webhooks are less resource-intensive.
A webhook is an HTTP request (typically a POST sent to a pre-defined callback URI, where the server application is configured to handle the request on that URI. In many cases, webhooks are triggered by stimulus events, making them a faster and more efficient method of handling events (push-based vs. poll-based).
Webhooks have two components: the outbound side (sender) and the inbound side (recipient). The recipient is responsible for specifying the callback URI so that the sender knows where to send the asynchronous request.
The outbound side is typically associated with some sort of stimulus event that gets triggered in the server code. This could be an event such as a status change on an object like assigning a pull request, or the completion of a process like publishing a release. Think of it as subscribe and notify model where the subscription may be long lasting, or transient – created and expired for the duration of a single stimulus request.
The inbound side of a webhook is the location or URI that the webhook is sent to. Recipients are expecting to receive webhooks and will take some form of action based on the contents of the received message. Hence, recipients of a webhook require setup and configuration to receive and handle the inbound request.
Webhooks are far more efficient than polling, from a resource and communication standpoint. Zapier did a study across 30 million poll requests made through their service, and found that 98.5% of polls are wasted and they spent 66x more resources on polling.
Data is always old. The very nature of webhooks and the fact that they are typically event-triggered means they are providing you with near real-time information. Due to this, if you want information as close to real-time as possible, you should elect to use webhooks over polling.
Webhooks are superior to polling in terms of freshness of data, efficiency of communication and infrastructure costs.
GitHub built webhooks for the convenience of developers. We know there are stimulus events that developers will to care about so we've tried to expose almost every conceivable event through our webhooks. Each webhook can be installed on an organization or a specific repository. Once installed, they will be triggered each time one or more subscribed events occurs on that organization or repository like deployments, commits, and repository changes, etc.
We recommend against the use of polling due to HTTP traffic and server load concerns. Let's say you set up a job running every minute that polls an API looking for code commits to trigger a code review. This job runs 24 hours a day, 365 days a year. That’s over 500,000 queries per year to the service, when in reality there are probably only 10 to 30 commits per day. That may not seem significant now, but scale that to the hundreds of events you might want to track on GitHub, and that might become a different story.
You can configure webhooks directly in your repository or organization settings:
Once you've configured a hook, the new deliveries section helps you track, troubleshoot, and re-send a webhook event payload:
You can learn more about implementing webhooks using code examples and other information from our Webhook Technical Guide <URL TBD>. Feel free to fork the site repository and issue a pull request. Happy coding 
!