Du webhook aux notifications push : guide

6 août 2026 · LogsNinja

Workflow échoué#deploys ·

Un webhook que vous recevez déjà

Stripe, GitHub, Supabase et la plupart des outils SaaS poussent déjà un payload JSON vers un endpoint que vous contrôlez dès que quelque chose se produit. Ce payload finit généralement dans un log, ou est ignoré en silence jusqu'à ce que quelque chose casse. Les champs dont vous avez besoin pour une alerte y sont déjà – il suffit de les transmettre.

Trois étapes dans le handler que vous avez déjà

Vérifiez la signature

Associez les champs

Envoyez l’événement

DU WEBHOOK À L’ÉVÉNEMENT

Un payload GitHub Actions, transmis comme événement

Vérifiez la signature, extrayez la conclusion et le nom du dépôt du payload, puis envoyez un appel HTTP – le même principe s'applique à Supabase, Stripe ou votre propre backend.

$ curl -X POST https://api.logsninja.com/v1/events \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -d '{
    "project": "YOUR_PROJECT_ID",
    "stream":  "deploys",
    "title":   "Workflow failed",
    "content": "deploy.yml on main",
    "emoji":    "🚨",
    "metadata": {"repo": "org/app"},
    "notify":   true
  }'

✓ Event received
✓ Push sent to 2 devices
# feed and chart updated

Sources de webhook courantes

Stripe

Paiements, factures et changements d’abonnement.

GitHub

Déploiements, pull requests et échecs de workflow.

Supabase

Changements de base de données et événements d’authentification.

Votre propre backend

Tout événement interne que vous émettez déjà sous forme de webhook.

Déployez-le en toute sécurité

Vérifiez avant de faire confiance

Vérifiez l'en-tête de signature du fournisseur avant de traiter quoi que ce soit – GitHub, Stripe et Supabase signent chacun leurs payloads.
Gardez votre secret de signature webhook et votre token API LogsNinja hors du code côté client.
Ne transmettez que les champs dont vous avez réellement besoin pour l'alerte ou le graphique, pas le payload complet.

Gérez les nouvelles tentatives

La plupart des fournisseurs relancent les webhooks non délivrés – renvoyez 200 rapidement et traitez de manière asynchrone si besoin.
Utilisez l'ID de livraison du fournisseur comme clé d'idempotence pour qu'un webhook relancé ne crée pas d'alerte en double.
Mettez notify à false pour les événements à fort volume que vous voulez seulement sur un graphique, pas en push.

Construisez ceci sur votre tableau de bord

Chaque widget ci-dessous lit les mêmes événements que vous venez de commencer à envoyer – pas de seconde intégration.

Déploiements aujourd'huiMis à jour

Workflows échouésMis à jour

Migrations de base de donnéesMis à jour

Valeurs d’exemple affichées à titre d’illustration.

Questions fréquentes

Ai-je besoin d'un nouvel endpoint pour ça ?

Non. Ajoutez un appel HTTP vers LogsNinja dans le handler qui reçoit déjà le webhook, après avoir vérifié sa signature.

Est-ce que ça fonctionne pour des webhooks autres que GitHub ?

Oui. Les mêmes trois étapes – vérifier, mapper les champs, envoyer l'événement – s'appliquent à Stripe, Supabase ou tout fournisseur qui envoie un payload JSON signé.

Et si je veux que seuls certains événements de webhook déclenchent une alerte, pas tous ?

Mettez notify à false pour ceux que vous voulez seulement sur un graphique, et true pour ceux qui méritent un push – les deux lisent le même payload.

Du webhook à la notification push en un appel HTTP