Loading...
Loading...
Learn how to test and debug GitHub repository webhooks using Webhook.it. This guide covers repository events, organization webhooks, and integration with CI/CD pipelines.
GitHub webhooks allow you to build integrations that subscribe to certain events on GitHub.com or GitHub Enterprise. When one of those events is triggered, GitHub sends an HTTP POST payload to the webhook's configured URL. Webhooks can be used to update external issue trackers, trigger CI builds, deploy to production, and much more.
You can configure webhooks at the repository level, organization level, or create GitHub Apps with webhook capabilities for broader access. Each webhook can subscribe to specific events or receive all events, making it flexible for different integration needs.
GitHub supports dozens of webhook event types. Here are the most commonly used events for development workflows:
push - Code pushed to a branch (most common for CI/CD)create - Branch or tag createddelete - Branch or tag deletedrelease - Release published, edited, or deletedrepository - Repository created, deleted, or visibility changedpull_request - PR opened, closed, merged, or synchronizedpull_request_review - Review submitted on a PRpull_request_review_comment - Comment on PR diffcheck_run - CI check completedcheck_suite - CI suite completedissues - Issue opened, closed, labeled, or assignedissue_comment - Comment on issue or PRdiscussion - Discussion created or answeredlabel - Label created, edited, or deletedworkflow_run - GitHub Actions workflow completedworkflow_job - Workflow job queued, started, or completeddeployment - Deployment createddeployment_status - Deployment status changedstatus - Commit status updatedVisit Webhook.it and copy your unique webhook URL. Keep this page open to monitor incoming events in real-time as you configure and test your GitHub webhook.
Go to your GitHub repository and click Settings > Webhooks > Add webhook. If you don't see the Webhooks option, ensure you have admin access to the repository. For organization-wide webhooks, go to Organization Settings > Webhooks.
Paste your Webhook.it URL in the "Payload URL" field. Set Content type toapplication/json. Choose which events to receive - "Send me everything" is useful for testing, or select specific events you need.
You can optionally set a secret token for signature verification. While not required for testing, it's essential for production webhooks to validate that requests come from GitHub.
After saving, GitHub sends a ping event to verify the webhook is working. Check Webhook.it to see this initial event. Then trigger real events by pushing code, creating an issue, or opening a pull request.
You can also redeliver past webhook events from the GitHub webhook settings page. Click on any recent delivery to see its details and click "Redeliver" to resend it.
GitHub webhook payloads vary by event type, but share common structural patterns. Understanding these helps you write efficient webhook handlers:
action - What happened (opened, closed, created, etc.)sender - User who triggered the eventrepository - Repository where event occurredorganization - Organization (if applicable)installation - GitHub App installation inforef - Full ref that was pushed (refs/heads/main)before - SHA of the previous HEAD commitafter - SHA of the new HEAD commitcommits - Array of commit objects pushedhead_commit - The most recent commitpusher - User who pushed the commitsGitHub includes several important headers with each webhook delivery. Inspect these in Webhook.it to understand the request context:
Use push andpull_request events to trigger builds, run tests, and deploy code. Check the reffield to filter by branch.
Sync GitHub issues with external tools like Jira or Linear usingissues andissue_comment events.
Post to Slack or Discord when PRs are opened, reviews are requested, or releases are published. Use the action field to customize messages.
Use Webhook.it to get a free public URL instantly. Go to your repository Settings > Webhooks > Add webhook, paste your Webhook.it URL, and select which events to receive. Push code or create a PR to trigger webhooks.
GitHub sends an X-Hub-Signature-256 header with each webhook. Compute the HMAC SHA-256 hash of the payload using your webhook secret, then compare it with the signature header. Always verify in production to prevent spoofed requests.
This header tells you which event type triggered the webhook (push, pull_request, issues, etc.). Use it to route webhooks to the correct handler before parsing the payload body.
Common issues: 1) Check the Recent Deliveries tab in webhook settings for errors, 2) Ensure your endpoint returns 2xx within 10 seconds, 3) Verify the URL is publicly accessible, 4) Check if the webhook is active and subscribed to the right events.
Yes! Go to your repository Settings > Webhooks, click on your webhook, and view Recent Deliveries. Click on any delivery to see details and use the 'Redeliver' button to resend it.