Integrations

GitLab Webhooks Guide

GitLab webhooks notify automation systems about project, group, push, merge request, issue, pipeline, and deployment activity. Once those events trigger CI, release, compliance, or internal workflow actions, they need reliable routing and recovery instead of direct delivery into one fragile endpoint.

FastHook supports GitLab legacy secret tokens and signed webhook headers, stores the original request, routes accepted events to destination branches, and keeps retry evidence visible for failed automation.

Branch-local provider routing rules for webhook events.
Keep GitLab branch, project, and event filters close to each destination branch so CI, deployment, and audit consumers stay isolated.

GitLab auth headers

  • x-gitlab-token: legacy secret token header.
  • webhook-signature: Svix-compatible signature header when signed webhooks are enabled.
  • webhook-id and webhook-timestamp: message id and timestamp for signed delivery.

Create a GitLab source

Create GitLab source
curl -X POST "https://api.fasthook.io/v1/sources" \
  -H "Authorization: Bearer $FASTHOOK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "GitLab production",
    "type": "GITLAB",
    "config": {
      "auth_type": "PROVIDER_SIGNATURE",
      "auth": {
        "provider": "GITLAB",
        "webhook_signing_secret": "provider-secret"
      },
      "allowed_http_methods": ["POST", "PUT", "PATCH", "DELETE"]
    }
  }'

Route by event owner

  • Push and merge request events can route to CI and preview environments.
  • Pipeline and deployment events can route to release dashboards.
  • Issue and comment events can route to support or project automation.
  • Group-level events can route to audit or compliance destinations.

Related guides