Webhook ne reçoit pas les requêtes de l'API Google Chat (fonctionne bien via appel HTTP direct)

Questions
1

Décrivez le problème/l’erreur/la question

J’ai un workflow publié utilisant un nœud Webhook (configuré avec
« Respond: Using Respond to Webhook Node ») agissant comme backend
pour une application Google Chat.
Problème :

  • Quand j’envoie une demande POST manuellement à mon URL de webhook
    de production (via PowerShell/Invoke-RestMethod), cela fonctionne
    parfaitement : l’exécution apparaît dans l’onglet Executions,
    s’exécute avec succès et retourne une réponse valide.
  • Quand Google Chat envoie un message à la même URL de webhook exacte
    (configurée dans Google Cloud Console > Google Chat API >
    Configuration > HTTP endpoint URL), AUCUNE exécution n’est jamais
    créée dans l’onglet Executions de n8n.
  • Du côté de Google, Google Cloud Logging affiche ces erreurs quand il
    tente de livrer le message :
    • code 3 : « Can’t post a reply. The Chat app didn’t respond or its
      response was invalid. »
    • code 13 : « Due to an internal error, Chat failed to process the
      bot response »
      Ceci suggère que la demande des serveurs de Google Chat n’atteint pas
      du tout mon workflow (aucune exécution enregistrée), tandis que des
      demandes identiques provenant d’autres sources l’atteignent sans
      problème.
      Questions :
  1. Y a-t-il un filtrage au niveau Cloudflare/WAF sur l’infrastructure
    de webhook partagée de n8n Cloud qui pourrait bloquer ou rejeter
    les demandes spécifiquement en provenance des serveurs de l’API
    Google Chat ?
  2. Existe-t-il un moyen de voir les journaux au niveau du périmètre
    (avant l’exécution du workflow) pour confirmer si la demande est
    rejetée avant d’atteindre mon workflow ?
    Merci de votre aide!

Quel est le message d’erreur (le cas échéant) ?

Veuillez partager votre workflow

(Sélectionnez les nœuds sur votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le workflow.)

Partagez le résultat retourné par le dernier nœud

Informations sur votre configuration n8n

  • Version n8n :
  • Base de données (par défaut : SQLite) :
  • Paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) :
  • Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) :
  • Système d’exploitation :
2

Salut @Octa-004 Bienvenue !
C’est presque certainement l’authentification de votre nœud Webhook, pas un blocage edge ou Cloudflare. Google Chat signe chaque requête avec son propre Authorization: Bearer <JWT> (émis par chat@system.gserviceaccount.com, User-Agent Google-Dynamite), il ne peut donc pas porter les identifiants que votre webhook attend. Avec l’authentification Header, Basic ou JWT activée sur le nœud Webhook, n8n rejette toute requête dont le jeton ne correspond pas et ne crée jamais d’exécution, ce qui explique exactement pourquoi votre appel PowerShell avec les bonnes identifiants fonctionne, Google Chat ne fonctionne pas, et Google enregistre « didn’t respond or its response was invalid ».
Définissez l’authentification du nœud Webhook sur None et republier ; les requêtes de Google atteindront alors le workflow et enregistreront les exécutions. Pour rester sécurisé sans authentification au niveau n8n, vérifiez plutôt le JWT de Google à l’intérieur du workflow : un nœud Code vérifiant l’émetteur chat@system.gserviceaccount.com et l’audience (le numéro de projet de votre application ou l’URL de point de terminaison), en rejetant tout ce qui échoue.
Sur vos deux questions : n8n Cloud ne bloque pas sélectivement les serveurs de Google ici, et les journaux edge pré-exécution ne sont pas exposés aux utilisateurs, donc c’est une vue réservée au support. Vous n’en avez pas besoin, car en désactivant l’authentification et en retestant, vous confirmez la cause en une seule étape.
Une fois que la livraison fonctionne, assurez-vous que le nœud Respond to Webhook retourne rapidement un JSON Chat valide comme {"text":"..."}, pour ne pas déclencher le code 3 pour une réponse véritablement invalide.
Verify requests from Google Chat  |  Google for Developers

3

Bon diagnostic de @Anshul_Namdev — l’incohérence d’authentification est exactement pourquoi votre appel PowerShell manuel crée une exécution alors que Google Chat ne le fait jamais. Google signe chaque requête avec son propre JWT Bearer, donc toute authentification Header/Basic/JWT sur le nœud Webhook la rejette avant qu’une exécution soit jamais créée.

L’élément à ajouter : une fois que vous définissez l’authentification du nœud Webhook sur « Aucune » pour laisser passer Chat, vous ne voulez pas que le point de terminaison reste grand ouvert. Validez plutôt le propre jeton de Google dans le flux. Déposez un nœud Code (ou IF) juste après le Webhook et vérifiez le JWT Bearer d’autorisation entrant :

  • l’émetteur (iss) doit être le compte de service du système Google Chat (chat@system.gserviceaccount, celui qui signe les requêtes Chat)
  • l’audience (aud) doit être égale au numéro de projet numérique de votre application Chat
  • vérifiez la signature par rapport aux certificats x509 publiés par Google pour ce même compte de service

Si l’une des vérifications échoue, arrêtez le flux de travail. Seul le trafic authentique de Google Chat porte un jeton qui réussit, donc le nœud Webhook reste ouvert (les requêtes de Chat créent enfin des exécutions) tandis que les appelants aléatoires sont filtrés. Cela vous donne la même protection que l’authentification du nœud tentait de fournir, sans bloquer l’expéditeur que vous voulez.

4

Même symptôme ici sur n8n 2.2.4 auto-hébergé, et l’explication de l’authentification ne correspond pas à mon cas.

Problème

  • POST manuel sur mon URL de webhook de production (curl, PowerShell) fonctionne : l’exécution apparaît, s’exécute, retourne la réponse attendue. HTTP 200.
  • Google Chat envoie vers cette même URL et aucune exécution n’est créée. Chaque exécution que ce webhook a jamais eu a un user-agent curl/8.5.0 ou PowerShell. Aucune requête d’origine Google n’a jamais apparu, pas même échouée.
  • Google Cloud Logging : code 13, « En raison d’une erreur interne, Chat n’a pas pu traiter la réponse du bot », 18 entrées.
  • L’authentification du nœud Webhook n’est pas la cause. Mes POSTs manuels n’envoient aucun en-tête Authorization et retournent quand même 200, donc le nœud n’impose pas une credential. Le workflow ne définit pas d’authentification — le nœud est simplement :

{ “httpMethod”: “POST”, “path”: “my-path”, “responseMode”: “responseNode”, “options”: {} }

typeVersion: 2, pas de clé d’authentification. Respond to Webhook retourne respondWith: json avec l’enveloppe hostAppDataAction.chatDataAction.createMessageAction.

Déjà vérifiés

  • URL de l’endpoint vérifiée caractère par caractère dans la console de l’API Chat, /webhook/ et non /webhook-test/.
  • « Build as a Workspace add-on » coché, statut de l’app LIVE, fonctionnalités interactives activées, URL HTTP commune pour tous les déclencheurs.
  • Trois reconstructions du début de l’app Chat dans trois nouveaux projets Google Cloud. Même résultat à chaque fois.

Questions

  1. Sur n8n auto-hébergé, où apparaît une requête qui atteint le processus mais ne crée jamais d’exécution ? N8N_LOG_LEVEL=debug enregistre-t-il un POST vers un chemin non enregistré, ou existe-t-il un autre moyen de confirmer l’arrivée ? Distinguer « Google n’a jamais envoyé » de « n8n l’a abandonné avant exécution » est le blocage.
  2. Un chemin de webhook de production peut-il ne pas s’enregistrer alors que le workflow est actif et que l’URL retourne 200 aux appels manuels — après une importation ou un workflow dupliqué ? Celui-ci a été importé via l’API REST et porte une chaîne webhookId lisible plutôt qu’un UUID.
  3. Dans la console de l’API Chat, le champ Service Account Email ne s’affiche pas du tout pour cette app — absent, pas vide, et aucune chaîne gsuiteaddons n’apparaît nulle part sur la page. Quelqu’un a-t-il rencontré cela, et cela indique-t-il que le déploiement du module complémentaire n’a jamais enregistré une cible de dispatch ?
5

Puisque @JGCoder a confirmé que le nœud Webhook n’utilise pas d’authentification et qu’une POST manuelle non authentifiée fonctionne, je diviserais le diagnostic avant de modifier les paramètres JWT :

  1. Vérifiez le journal d’accès du reverse-proxy/ingress en envoyant un événement de test Google Chat. Si aucune requête d’origine Google n’apparaît, l’échec est en amont de n8n : vérifiez l’URL exacte en production de l’application Chat, la méthode POST, le déploiement/la disponibilité et l’accès de l’utilisateur test.
  2. Si la requête apparaît avec 30x ou 403, corrigez la redirection, le WAF ou la règle TLS/proxy.
  3. Si elle atteint n8n mais ne crée aucune exécution, vérifiez l’enregistrement du webhook publié plus le chemin et la méthode exacts.

Pour un test, réduisez le workflow à Webhook (POST, URL production) -> Respond to Webhook et retournez HTTP 200 dans quelques secondes avec {"text":"ok"}. Comparez ensuite l’URL et le statut affichés dans Google Cloud Logging avec le journal du proxy. Cela identifie si le défaut provient de la livraison Google Chat, de l’edge/proxy ou de n8n lui-même.