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)