Notifications Webhook
Les webhooks vous permettent de recevoir des notifications HTTP POST en temps réel chaque fois que quelque chose change dans votre espace Archyl. Créez un webhook, pointez-le vers votre URL, sélectionnez les événements qui vous intéressent, et Archyl notifiera votre endpoint à chaque déclenchement.
Vue d'ensemble
Lorsqu'un événement se produit — un système est créé, une release est déployée, un ADR est mis à jour — Archyl envoie une requête HTTP POST à chaque webhook abonné à cet événement. Votre endpoint reçoit un payload JSON décrivant ce qui s'est passé, qui l'a fait, et à quel projet cela appartient.
Cas d'utilisation courants :
- Notifications Slack ou Teams lorsque des changements d'architecture sont effectués
- Déclencheurs CI/CD lors de la création d'une nouvelle release
- Journalisation d'audit vers un système externe
- Tableaux de bord personnalisés qui réagissent aux événements d'architecture
- Pipelines d'automatisation qui s'exécutent à la fin des découvertes
Événements Supportés
Éléments d'Architecture
| Catégorie | Événements |
|---|---|
| Systèmes | system.created, system.updated, system.deleted |
| Conteneurs | container.created, container.updated, container.deleted |
| Composants | component.created, component.updated, component.deleted |
| Code | code.created, code.updated, code.deleted |
| Relations | relationship.created, relationship.updated, relationship.deleted |
| Overlays | overlay.created, overlay.updated, overlay.deleted |
Gestion de Projet
| Catégorie | Événements |
|---|---|
| Projets | project.created, project.updated, project.deleted |
| Releases | release.created, release.updated, release.deployed |
| Demandes | request.created, request.merged, request.closed |
Documentation
| Catégorie | Événements |
|---|---|
| ADR | adr.created, adr.updated, adr.deleted |
| Documentation | documentation.created, documentation.updated, documentation.deleted |
| Flows | flow.created, flow.updated, flow.deleted |
| Contrats d'API | api_contract.created, api_contract.updated |
Collaboration et Analyse
| Catégorie | Événements |
|---|---|
| Commentaires | comment.created |
| Whiteboards | whiteboard.created |
| Canaux d'événements | event_channel.created |
| Découverte | discovery.completed |
| Insights | insight.generated |
Créer un Webhook
- Allez dans les Paramètres de l'organisation et sélectionnez l'onglet Webhooks
- Cliquez sur Nouveau Webhook
- Remplissez la configuration :
| Champ | Requis | Description |
|---|---|---|
| Nom | Oui | Un libellé descriptif (ex. "Slack — Changements d'architecture") |
| URL | Oui | L'endpoint HTTPS qui recevra les requêtes POST |
| Token secret | Non | Un secret partagé utilisé pour signer les payloads à des fins de vérification |
| Événements | Oui | Sélectionnez les événements qui déclenchent ce webhook |
| Projets | Non | Restreindre optionnellement à des projets spécifiques |
- Cliquez sur Créer
Le webhook commence à recevoir des événements immédiatement.
Format du Payload
Chaque livraison de webhook envoie un payload JSON avec cette structure :
{
"event": "system.created",
"timestamp": "2026-03-10T14:30:00Z",
"data": {
"entityType": "system",
"entityName": "Payment Service",
"action": "created",
"userName": "vincent",
"projectId": "a1b2c3d4-...",
"projectName": "My Project"
}
}
| Champ | Description |
|---|---|
event |
La chaîne du type d'événement (ex. container.updated, release.deployed) |
timestamp |
Horodatage ISO 8601 du moment où l'événement s'est produit |
data.entityType |
Le type d'entité qui a changé |
data.entityName |
Le nom de l'entité concernée |
data.action |
L'action qui a été effectuée |
data.userName |
L'utilisateur qui a déclenché l'événement |
data.projectId |
UUID du projet où l'événement s'est produit |
data.projectName |
Nom lisible du projet |
Le header Content-Type est toujours application/json.
Sécurité
Headers de Requête
Chaque livraison de webhook inclut ces headers :
| Header | Exemple | Description |
|---|---|---|
Content-Type |
application/json |
Toujours JSON |
User-Agent |
Archyl-Webhook/1.0 |
Identifie la requête comme provenant d'Archyl |
X-Archyl-Event |
system.created |
Le type d'événement qui a déclenché cette livraison |
X-Archyl-Signature |
sha256=a1b2c3... |
Signature HMAC-SHA256 (uniquement si un token secret est défini) |
Vérification de Signature HMAC-SHA256
Si vous définissez un token secret lors de la création du webhook, Archyl signe chaque payload avec HMAC-SHA256. La signature est envoyée dans le header X-Archyl-Signature avec le format :
sha256=<digest HMAC-SHA256 encodé en hexadécimal>
Pour vérifier une livraison :
- Lisez le corps brut de la requête (les octets exacts, avant tout parsing JSON)
- Lisez le header
X-Archyl-Signatureet retirez le préfixesha256=pour obtenir la signature hexadécimale - Calculez un hash HMAC-SHA256 du corps brut en utilisant votre token secret comme clé
- Encodez le résultat en hexadécimal et comparez-le à la signature de l'étape 2 en utilisant une comparaison en temps constant
- Rejetez la requête si les valeurs ne correspondent pas
Exemple Go :
func verifyArchylWebhook(r *http.Request, secret string) ([]byte, error) {
body, err := io.ReadAll(r.Body)
if err != nil {
return nil, err
}
header := r.Header.Get("X-Archyl-Signature")
if !strings.HasPrefix(header, "sha256=") {
return nil, fmt.Errorf("missing or invalid signature header")
}
signature := strings.TrimPrefix(header, "sha256=")
mac := hmac.New(sha256.New, []byte(secret))
mac.Write(body)
expected := hex.EncodeToString(mac.Sum(nil))
if !hmac.Equal([]byte(expected), []byte(signature)) {
return nil, fmt.Errorf("signature mismatch")
}
return body, nil
}
Exemple Node.js :
const crypto = require("crypto");
function verifyArchylWebhook(req, secret) {
const header = req.headers["x-archyl-signature"] || "";
if (!header.startsWith("sha256=")) {
throw new Error("Missing or invalid signature header");
}
const signature = header.slice("sha256=".length);
const body = req.rawBody; // use raw body, not parsed JSON
const expected = crypto
.createHmac("sha256", secret)
.update(body)
.digest("hex");
if (!crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(signature))) {
throw new Error("Signature mismatch");
}
return JSON.parse(body);
}
Exemple Python :
import hmac
import hashlib
def verify_archyl_webhook(body: bytes, header: str, secret: str) -> dict:
if not header.startswith("sha256="):
raise ValueError("Missing or invalid signature header")
signature = header.removeprefix("sha256=")
expected = hmac.new(
secret.encode(), body, hashlib.sha256
).hexdigest()
if not hmac.compare_digest(expected, signature):
raise ValueError("Signature mismatch")
return json.loads(body)
Utilisez toujours une comparaison en temps constant (hmac.Equal, crypto.timingSafeEqual, hmac.compare_digest) pour prévenir les attaques par timing. Vérifiez toujours contre le corps brut de la requête -- parser et re-sérialiser le JSON peut modifier la représentation en octets et invalider la signature.
Historique des Livraisons
Chaque webhook conserve un journal des livraisons récentes. Pour le consulter :
- Allez dans Paramètres de l'organisation > Webhooks
- Cliquez sur le nom du webhook
- Ouvrez l'onglet Livraisons
Chaque entrée de livraison affiche :
| Champ | Description |
|---|---|
| Événement | Le type d'événement qui a déclenché la livraison |
| Code de statut | Le code de réponse HTTP de votre endpoint |
| Horodatage | Quand la livraison a été envoyée |
| Durée | Combien de temps la requête a pris |
| Payload de la requête | Le corps JSON complet qui a été envoyé |
| Corps de la réponse | La réponse retournée par votre endpoint |
Les livraisons sont conservées pendant 7 jours. Après cette période, elles sont automatiquement purgées.
Un badge vert indique une livraison réussie (réponse 2xx). Un badge rouge indique un échec (réponse non-2xx ou timeout).
Test
Avant de vous fier à un webhook en production, vérifiez qu'il fonctionne :
- Ouvrez la page de détail du webhook
- Cliquez sur Envoyer un Test
- Archyl envoie un payload de test à votre endpoint avec
event: "webhook.test" - Vérifiez l'onglet Livraisons pour confirmer la réception et inspecter la réponse
La livraison de test utilise le même mécanisme de signature que les événements réels, vous pouvez donc valider votre logique de vérification de signature en même temps.
Politique de Retry
Lorsqu'une livraison échoue (réponse non-2xx ou timeout réseau), Archyl effectue automatiquement des retentatives :
| Tentative | Délai |
|---|---|
| 1re retentative | 1 minute |
| 2e retentative | 5 minutes |
| 3e retentative | 30 minutes |
Après 3 retentatives échouées, la livraison est marquée comme échouée. Vous pouvez relancer manuellement toute livraison échouée depuis l'onglet Livraisons en cliquant sur Réessayer.
Si un webhook échoue de manière continue pendant 24 heures, Archyl le désactive et envoie une notification aux administrateurs de l'organisation. Réactivez-le depuis les paramètres du webhook une fois le problème résolu.
Filtrage par Projets
Par défaut, un webhook reçoit les événements de tous les projets de l'organisation. Pour restreindre le périmètre :
- Modifiez le webhook
- Sous Projets, sélectionnez un ou plusieurs projets
- Enregistrez
Seuls les événements provenant des projets sélectionnés déclencheront des livraisons. C'est utile lorsque différentes équipes gèrent différents projets et n'ont besoin de notifications que pour leur propre travail.
Vous pouvez mettre à jour le filtre de projets à tout moment sans recréer le webhook.
Bonnes Pratiques
Répondez Rapidement
Votre endpoint doit retourner une réponse 2xx en moins de 10 secondes. Si vous avez besoin d'effectuer un traitement lourd, acceptez le webhook immédiatement et traitez le travail de manière asynchrone dans une tâche en arrière-plan.
Vérifiez les Signatures
Définissez toujours un token secret et vérifiez le header X-Archyl-Signature. Cela garantit que les payloads proviennent bien d'Archyl et n'ont pas été altérés.
Utilisez HTTPS
Utilisez toujours un endpoint HTTPS. Archyl ne livrera pas de webhooks vers des URLs HTTP non sécurisées.
Filtrez par Projet
Si votre organisation a de nombreux projets, limitez les webhooks aux projets qui vous concernent. Cela réduit le bruit et évite les traitements inutiles de votre côté.
Gérez les Doublons
Dans de rares cas (retentatives réseau, basculement d'infrastructure), votre endpoint peut recevoir le même événement plus d'une fois. Utilisez les champs timestamp et event pour détecter et dédupliquer.
Surveillez la Santé des Livraisons
Consultez l'onglet Livraisons périodiquement. Un schéma d'échecs récurrents peut indiquer des problèmes d'endpoint, des règles de pare-feu ou des identifiants expirés de votre côté.
Prochaines Étapes
- Intégrations Marketplace — Connectez des services externes et affichez des données en temps réel sur vos tableaux de bord
- Gestion des Releases — Suivez les déploiements à travers votre architecture
- Insights d'Architecture — Détectez les problèmes architecturaux automatiquement