Ajoutez un webhook GitLab de projet ou de groupe, choisissez les déclencheurs, vérifiez l'en-tête webhook-signature ou X-Gitlab-Token, et découvrez quand GitLab désactive un hook en échec.
Un webhook GitLab envoie une requête HTTP POST à votre URL lorsqu'un événement se produit dans un projet ou un groupe, comme un push, une merge request ou un nouveau commentaire. Ajoutez-en un dans Paramètres, Webhooks. Protégez-le avec un jeton de signature et répondez rapidement avec 200, car GitLab désactive les hooks qui échouent de façon répétée.
Les webhooks GitLab en chiffres (docs.gitlab.com, octobre 2026)
Les webhooks permettent à GitLab de prévenir votre site, votre script de déploiement ou la messagerie de votre équipe qu'un changement a eu lieu, sans que votre code doive interroger GitLab en boucle. La configuration prend une minute ; ce qui pose problème ensuite, c'est de prouver qu'une requête vient bien de GitLab et d'éviter que le hook soit désactivé. Le vérificateur ci-dessous calcule une signature de jeton de signature dans votre navigateur pour que vous puissiez tester votre récepteur.
C'est l'ancien jeton secret. Lorsque vous en définissez un, GitLab l'envoie en texte clair dans l'en-tête X-Gitlab-Token et votre serveur le compare. La documentation de GitLab recommande désormais plutôt un jeton de signature pour les nouveaux webhooks.
GitLab désactive un hook après quatre échecs consécutifs, c'est-à-dire des réponses 4xx ou 5xx, des délais de connexion dépassés ou d'autres erreurs HTTP. Il est d'abord coupé une minute, puis plus longtemps à chaque nouvel échec jusqu'à 24 heures, et définitivement après 40 échecs d'affilée.
Lisez l'en-tête X-Gitlab-Event. Sa valeur est le type d'événement suivi de Hook, par exemple Push Hook, Merge Request Hook, Note Hook pour les commentaires ou Pipeline Hook.
Oui, avec les offres Premium et Ultimate. Un webhook de groupe se déclenche pour les événements de chaque projet du groupe, et peut aussi recevoir les événements de membres du groupe, de projets et de sous-groupes.
La documentation de GitLab indique qu'il est arrivé dans la version 19.0 derrière un feature flag activé par défaut, et qu'il est devenu disponible pour tous dans la 19.1. Les versions auto-hébergées plus anciennes n'ont que le jeton secret.
Ce récepteur vérifie la signature du jeton de signature, rejette les horodatages périmés et revient à l'ancien jeton secret pendant la migration.
Les jetons proviennent de variables d'environnement. La fenêtre de fraîcheur de cinq minutes est notre propre choix ; choisissez ce qui vous convient.
Événements de webhook GitLab
Saisissez un jeton de signature, le webhook-id, le webhook-timestamp et le corps brut pour obtenir la valeur webhook-signature que GitLab enverrait. Tout s'exécute dans votre navigateur.
Jeton de signature (commence par whsec_)
Corps brut de la requête
Le jeton doit commencer par whsec_ suivi d'un texte en base64.
Le jeton prérempli est un exemple inventé, pas une vraie clé. Avec ces valeurs, le résultat est :
Quand GitLab désactive-t-il un hook ?
Livraisons échouées consécutives : {n}
Actif : les livraisons continuent.
Désactivé temporairement : coupé 1 minute au début, plus longtemps après chaque nouvel échec, jusqu'à 24 heures, puis réactivé automatiquement.
Désactivé définitivement : il reste coupé jusqu'à ce qu'une requête de test reçoive une réponse 2xx.
Commencer gratuitement · Sans carte bancaire