HookGet Open dashboard

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

FieldValue
Provider keygithub
Header checkedX-Hub-Signature-256: sha256=<hex>
SchemeHMAC-SHA256 over the raw request body, hex-encoded, compared in constant time.
Deduplicated onX-GitHub-Delivery
Event typeX-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_…"}
  1. In the repository or organisation, open Settings → Webhooks → Add webhook.
  2. Paste the ingest URL as the payload URL and the source secret as the secret.
  3. Choose application/json as the content type.
  4. 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.