From a functionality point of view, webhooks are a way to "emulate" push messages to a subscriber. To give a real example, every time you push a commit to one of your Github repo (on which you setup the webhook previously), Github can trigger a webhook to another third-party service. In our use-cases, any push to Github and Bitbucket triggers a build step on Wercker that builds a Docker image, test it then push it to the image registry (and eventually update an Amazon EC2 task-definition with this new image to deploy the update)

Ultimately, if you want to only get the idea, you should really think as a way to subscribe to push messages.

You can check Github documentation about their webhooks: developer.github.com/webhooks

Webhooks allow you to build or set up integrations which subscribe to certain events on GitHub.com. When one of those events is triggered, we'll send a HTTP POST payload to the webhook's configured URL. Webhooks can be used to update an external issue tracker, trigger CI builds, update a backup mirror, or even deploy to your production server. You're only limited by your imagination.

The beginning of Bitbucket documentation could also bring some light: confluence.atlassian.com/bitbucket/manage-webhook… (read the When to Use Webhooks and Advantages of Webhooks sections)

Docker Hub has Webhooks for example - once you've pushed a new docker image, it will do an HTTP POST to your Web Hook which might be a Jenkins build or whatever you want it to be. Based on the hook, you can now deploy that new Docker image.

SVN has Pre-Commit and Post-Commit Hooks, once you've committed code, it will do something, this something was often a WGET to a URL which is similar to a Web Hook which was often times used to trigger a Hudson build after each commit.

Gitlab has Webhooks which can be used to Trigger issue updates in Jira.

So in short, web hooks can be explained like this,

Action Happened or is About To Happen -> POST / GET to Web-Hook-Url -> Another Action Happens