Endpoints, events, and verification
| Provider | Webhook URL | Events | Verification |
|---|---|---|---|
| GitHub.com | https://app.gecko.security/api/github/webhook | pull_request, issue_comment, push | X-Hub-Signature-256 (HMAC-SHA256) |
| GitHub Enterprise | https://app.gecko.security/api/github-enterprise/webhook | Pull requests, Pushes | X-Hub-Signature-256 (per-connection secret) |
| GitLab | https://app.gecko.security/api/gitlab/webhook | Merge request, Push, Note (MR comments), Vulnerability | X-Gitlab-Token (shared secret) |
Always use the exact URL and secret shown in Gecko when you connect the
provider; secrets are generated per team (GitHub/GitLab) or per connection
(GitHub Enterprise).
GitHub & GitHub Enterprise
GitHub signs each delivery with an HMAC-SHA256 signature in theX-Hub-Signature-256 header. Gecko verifies it against the webhook secret and
supports multiple secrets at once, so you can rotate without downtime. For GHES,
set the content type to application/json.
GitLab
GitLab sends your secret token verbatim in theX-Gitlab-Token header.
Gecko compares it against the per-team secret generated at connection time.
Network direction
Webhooks are outbound from your instance to Gecko atapp.gecko.security.
This is the opposite direction from cloning and API calls. Your network must be
able to reach app.gecko.security on HTTPS, but webhooks don’t require you to
allowlist Gecko’s IP addresses; those are for the
outbound paths.
Troubleshooting
Deliveries fail with 401 or 403
Deliveries fail with 401 or 403
The secret doesn’t match. Re-copy the secret from Gecko into the provider’s
secret field.
No PR scans are triggering
No PR scans are triggering
Confirm the right events are enabled (pull/merge request and push) and that
the webhook delivery log in your provider shows
2xx responses.