GitHub webhooks
Repository, organisation and app events, verified with the signature GitHub already sends.
In short
- Verification: the provider’s own HMAC signature over the raw body.
- Deduplication:
X-GitHub-Delivery. - Once verified, the event joins your catalogue with the same retries, log and replay as anything you publish yourself.
The contract
| Field | Value |
|---|---|
| Provider key | github |
| Header checked | X-Hub-Signature-256: sha256=<hex> |
| Scheme | HMAC-SHA256 over the raw request body, hex-encoded, compared in constant time. |
| Deduplicated on | X-GitHub-Delivery |
| Event type | X-GitHub-Event becomes github.push, github.pull_request, and so on. |
Setting it up
# 1. create a verified source; the secret is shown once
curl -X POST https://api.hookget.com/v1/sources \
-H "authorization: Bearer $HOOKGET_KEY" \
-H "content-type: application/json" \
-d '{"provider":"github","name":"Production"}'
# {"id":"src_…","secret":"whsec_…","ingest_path":"/ingest/src_…"}
- In the repository or organisation, open Settings → Webhooks → Add webhook.
- Paste the ingest URL as the payload URL and the source secret as the secret.
- Choose application/json as the content type.
- Select the events you want. HookGet namespaces whatever arrives.
Worth knowing. GitHub redelivers on your request and after failures. The delivery id is the dedupe key, so a redelivery becomes the same event rather than a second one.
What you get after verification
- The event appears in your log with a namespaced type, so GitHub traffic never collides with your own.
- It fans out to your destinations with the same retry schedule and dead-letter behaviour as any other event.
- The source secret rotates with an overlap window, so you can update GitHub at your own pace.
- Each inbound source is rate limited on its own, so a busy provider cannot exhaust your publish budget.
Questions
How do I verify a GitHub webhook?
HMAC-SHA256 over the raw request body, hex-encoded, compared in constant time. With HookGet you do not implement it: the source is created with a secret,
and every request is checked against X-Hub-Signature-256: sha256=<hex> before the event exists.
What happens if GitHub sends the same event twice?
Redeliveries are deduplicated on X-GitHub-Delivery, namespaced per source, so a repeat becomes
the same event rather than a second one.
What if verification fails?
The request is refused with 401 and nothing enters the pipeline. The rejection is logged on our side as a signal worth watching; the caller learns nothing beyond the status.