Envoi manuel et monitoring des webhooks
Envoi manuel et monitoring des webhooks
Comment envoyer un document manuellement à une destination et suivre sa livraison via les journaux
Envoyez un document à une destination externe (webhook) depuis la fenêtre de document, testez une destination et interprétez les journaux pour diagnostiquer les livraisons.
Ce que couvre cette page
Envoi manuel
Choisir une destination dans la fenêtre de document et déclencher l’envoi immédiatement.
Test de destination
Envoyer une requête de test depuis la configuration de la destination pour vérifier payload, en-têtes et signature.
Monitoring et logs
Suivre les tentatives, lire les réponses HTTP et interpréter les statuts (succès, erreur, retry).
Relance et gestion d'erreurs
Comprendre quand relancer manuellement et quelles actions corriger selon l’erreur retournée.
Conseils pratiques
Bonnes pratiques pour payload, en-têtes d’authentification et limiter les erreurs courantes.
Scénarios
Différents scénarios expliqués : envoi immédiat, envoi de test, échecs transitoires et permanents.
Introduction Cette page explique étape par étape comment envoyer manuellement un document vers une destination externe (webhook) depuis la fenêtre de document, comment effectuer un envoi de test depuis la configuration de la destination, et comment surveiller et interpréter les journaux (logs) pour vérifier la réussite ou diagnostiquer les erreurs. Vous trouverez des conseils pratiques, les erreurs fréquentes et les actions recommandées.
Préparation : vérifier la destination et les permissions
Étape 1 — Vérifier la destination
Ouvrez la liste des destinations configurées pour votre projet. Confirmez que la destination ciblée est active, affectée au bon projet et que les paramètres importants (URL, en-têtes d’authentification, clé de signature) sont renseignés.
Étape 2 — S’assurer des permissions
Vérifiez que votre compte a les droits sur le projet et la permission d’envoyer des documents vers la destination. Si vous ne pouvez pas sélectionner la destination dans la fenêtre de document, demandez les droits au propriétaire du projet.
Étape 3 — Vérifier la compatibilité du payload
Relisez le template de payload configuré sur la destination (si présent). Assurez-vous que les champs nécessaires sont fournis par le document (titre, contenu, métadonnées).
Étape 4 — Note sur les destinations modèles
Certaines destinations peuvent être des modèles partagés. Ces destinations ne sont pas utilisables directement pour un envoi ; dupliquez-les dans votre projet avant de les utiliser.
Workflow principal : envoyer un document manuellement (DialogDocument)
Étape 1 — Ouvrir le document
Dans la liste des documents du projet, ouvrez le document que vous souhaitez envoyer. Utilisez la commande d’édition/aperçu qui affiche la fenêtre de document (DialogDocument).
Étape 2 — Choisir la destination
Dans la fenêtre, localisez le sélecteur “Destination” ou “Send to”. Cliquez et sélectionnez la destination webhook souhaitée dans la liste déroulante.
Étape 3 — Vérifier le contenu et options
Avant d’envoyer, vérifiez le contenu du document, le format (Markdown/JSON) et, si disponible, le template de payload appliqué à la destination.
Étape 4 — Lancer l’envoi
Cliquez sur le bouton “Send” ou “Envoyer”. Un retour immédiat vous confirmera que la requête a été déclenchée. Conservez cette confirmation pour la corrélation avec les logs.
Étape 5 — Consulter la confirmation
Après l’envoi, l’interface fournit généralement une confirmation (message d’alerte ou valeur de retour). Notez s’il y a un objet de réponse ou un identifiant de requête affiché.
Étape 6 — Aller surveiller les logs
Rendez-vous dans l’onglet de journaux/Changelogs ou dans l’onglet Commits du projet pour suivre la tentative d’acheminement (voir section Monitoring ci‑dessous).
Astuce — copiez la réponse immédiate
Si l’interface retourne un objet de requête ou un message après l’envoi, copiez-le. Il aide à retrouver la ligne de log correspondante (timestamp + document id) et accélère le diagnostic en cas d’échec.
Tester une destination depuis sa configuration (envoi de test)
Étape 1 — Ouvrir la configuration de la destination
Accédez à la gestion des destinations de votre projet et éditez la destination cible.
Étape 2 — Lancer le test
Utilisez le bouton de test prévu dans la fenêtre. Le test enverra une requête factice selon la configuration actuelle (payload & en-têtes).
Étape 3 — Télécharger la requête de test
Après le test, un fichier JSON de la requête générée peut être proposé en téléchargement. Ouvrez-le pour valider le payload, les en-têtes et la signature.
Étape 4 — Corriger la configuration si besoin
Si la requête de test ne correspond pas au format attendu par le récepteur, ajustez le template de payload, les paramètres de query, ou les en-têtes, puis relancez le test.
Étape 5 — Réessayer avec un document réel
Quand le test est concluant, revenez au document réel et faites l’envoi manuel.
Astuce — utiliser le test pour valider la signature
Vérifiez la valeur de la clé de signature et l’horodatage du serveur si votre récepteur valide les signatures temporelles. Un test local permet d’identifier rapidement un mauvais secret ou un problème d’horloge.
Attention — destinations modèles et permissions
Ne tentez pas d’envoyer un document vers une destination qui est marquée comme modèle partagé : l’envoi peut être refusé. Si l’envoi est bloqué, dupliquez la destination dans le projet et réessayez.
Monitoring : comment lire les journaux et suivre une livraison
Étape 1 — Ouvrir l’onglet Journaux / Changelogs
Depuis la vue du projet, ouvrez l’onglet “Changelogs” ou “Commits” où sont listées les tentatives de génération et d’envoi.
Étape 2 — Filtrer par document ou période
Utilisez les filtres (document, agent, période) pour réduire la liste. Recherchez le document envoyé et la période correspondant à l’heure d’envoi notée lors du step d’envoi.
Étape 3 — Ouvrir l’entrée de log détaillée
Cliquez sur la ligne correspondante pour afficher le détail : horodatage, type d’opération, destination cible, réponse HTTP, et contenu de la réponse (body).
Étape 4 — Identifier le statut
Repérez le badge de statut (succès, erreur, retry). Notez le code HTTP renvoyé (200, 400, 401, 500, etc.) et le message du récepteur.
Étape 5 — Relier aux tentatives
Si la livraison nécessite plusieurs tentatives, vous verrez une série d’entrées temporelles avec la progression (chaque essai a son horodatage et sa réponse). Comparez les réponses successives pour comprendre l’évolution.
Étape 6 — Exporter ou copier les logs
Si vous devez partager le diagnostic avec une équipe externe, exportez ou copiez le contenu du log (payload envoyé, en-têtes et réponse) et joignez-le au ticket de support.
Interpréter les statuts et réponses courantes
Succès (2xx)
Tout code de la famille 2xx indique que le récepteur a accepté la requête. Aucun nouvel essai n’est nécessaire. Vérifiez le contenu reçu côté destinataire si besoin.
Redirection ou réponse inattendue (3xx)
Les redirections peuvent être suivies ou rejetées selon la configuration du récepteur. Si la réponse n’est pas traitée comme un succès, adaptez l’URL de destination pour pointer directement à la cible finale.
Erreur client (4xx) — corriger la configuration
Codes 400/401/403 signifient généralement un problème de payload, d’authentification ou d’autorisation. Vérifiez les en-têtes d’auth, la clé/secret, et la structure du payload.
Erreur serveur (5xx) — transitoire, retrys possibles
Codes 5xx indiquent un problème côté récepteur (p.ex. surcharge). Ces erreurs entraînent normalement des tentatives de ré-envoi automatiques selon la politique de retries configurée.
Timeout / DNS / connexion refusée — échec réseau
Si la requête n’atteint pas la destination (timeout, DNS, connexion refusée), la livraison échoue et sera susceptible d’être retentée automatiquement. Vérifiez l’accessibilité de l’URL depuis votre réseau.
Signature invalide ou horodatage
Si le récepteur rejette la requête pour signature invalide, vérifiez le secret configuré et l’horloge serveur (décalage d’heure). Corrigez le secret et relancez un test.
Gérer les échecs et relancer manuellement
Étape 1 — Identifier le type d’erreur
À partir de la sortie du log, distinguez si l’échec est lié à : payload, auth, réseau, ou erreur côté récepteur.
Étape 2 — Appliquer la correction
Corrigez la configuration : header d’authorization, secret, template payload, URL, ou augmentez les timeouts si le récepteur est lent.
Étape 3 — Re-tester la destination
Effectuez un envoi de test depuis la configuration de la destination pour valider la correction avant de ré-envoyer un vrai document.
Étape 4 — Relancer l’envoi réel
Retournez sur le document et cliquez de nouveau sur “Send”. Suivez la nouvelle tentative via les logs.
Étape 5 — Si le problème persiste
Si plusieurs tentatives échouent malgré les corrections, contactez l’équipe qui gère la destination avec les logs (payload + headers + réponses) pour un diagnostic côté récepteur.
Utilisez ce scénario lorsque le document est prêt et que vous voulez le publier/transmettre à la destination. Cible typique : publication d’un article, notification de release, envoi d’un résumé. Conseil : testez la destination avant l’envoi réel.
Quand utiliser l’envoi de test
- Valider le template payload ou les en-têtes.
- Vérifier la signature sans envoyer de vrai contenu.
- Déboguer erreurs 4xx/401 localement.
Quand envoyer un document réel
- Contenu finalisé et approuvé.
- Destination validée par les tests.
- Nécessité de transmettre la donnée au flux de production.
Comportement des tentatives automatiques (retries)
Les ré-envois automatiques suivent la politique de la plateforme : nombre de retries et secondes d’attente (backoff). Un échec répété peut durer plusieurs tentatives et ne doit pas être confondu avec une suppression définitive. Si vous avez modifié la destination, relancez manuellement après validation plutôt que d’attendre toutes les tentatives automatiques.
Bonnes pratiques pour minimiser les erreurs
- Utilisez des en-têtes d’authentification standard et testez-les avec l’outil de test.
- Préférez des payloads simples lors des tests pour isoler les erreurs.
- Conservez les logs d’envoi (horodatage, id document) pour corrélation en cas de ticket.
Questions fréquentes — Envoi manuel et monitoring
Prêt à tester ?
Commencez par un envoi de test sur la destination, puis envoyez un document réel en suivant les étapes ci‑dessus. Si vous avez besoin d’aide, collectez les logs et contactez le support avec les détails.