Webhooks allow you to build or set up integrations, such as GitHub Apps or OAuth Apps, 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.
Webhooks can be installed on a GitHub Enterprise Server instance, an organization, a specific repository, or a GitHub App. Once installed, the webhook will be sent each time one or more subscribed events occurs.
You can create up to 250 webhooks for each event on each installation target (GitHub Enterprise Server instance, specific organization, or specific repository).
When configuring a webhook, you can use the UI or API to choose which events will send you payloads. Only subscribing to the specific events you plan on handling limits the number of HTTP requests to your server. You can also subscribe to all current and future events. By default, webhooks are only subscribed to the push event. You can change the list of subscribed events anytime.
Each event corresponds to a certain set of actions that can happen to your organization and/or repository. For example, if you subscribe to the
issues event you'll receive detailed payloads every time an issue is opened, closed, labeled, etc.
See "Webhook event payloads" for the list of available webhook events and their payloads.
When you create a new webhook, we'll send you a simple
ping event to let you know you've set up the webhook correctly. This event isnt stored so it isn't retrievable via the Events API. You can trigger a
ping again by calling the Ping a repository webhook endpoint.
For more information about the
ping event webhook payload, see the