Webhook not receiving requests from Google Chat API (works fine via direct HTTP call)

Questions
1

Describe the problem/error/question

I have a published workflow using a Webhook node (configured with
“Respond: Using Respond to Webhook Node”) acting as the backend for
a Google Chat app.
Issue:

  • When I send a POST request to my production webhook URL manually
    (via PowerShell/Invoke-RestMethod), it works perfectly: the
    execution appears in the Executions tab, runs successfully, and
    returns a valid response.
  • When Google Chat sends a message to the same exact webhook URL
    (configured in Google Cloud Console > Google Chat API >
    Configuration > HTTP endpoint URL), NO execution is ever created
    in n8n’s Executions tab.
  • On Google’s side, Google Cloud Logging shows these errors when it
    tries to deliver the 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”
      This suggests the request from Google Chat’s servers isn’t reaching
      my workflow at all (no execution logged), while identical requests
      from other sources reach it without issue.
      Questions:
  1. Is there any Cloudflare/WAF-level filtering on n8n Cloud’s shared
    webhook infrastructure that could be blocking or rejecting
    requests specifically from Google Chat API’s servers?
  2. Is there a way to see edge-level logs (before workflow execution)
    to confirm whether the request is being rejected before reaching
    my workflow?
    Thanks for your help!unavailable), please contact support at help@n8n.io →

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
2

Hi @Octa-004 Welcome!
This is almost certainly your Webhook node’s Authentication, not an edge or Cloudflare block. Google Chat signs every request with its own Authorization: Bearer <JWT> (issued by chat@system.gserviceaccount.com, User-Agent Google-Dynamite), so it cannot carry whatever credential your webhook expects. With Header, Basic, or JWT auth enabled on the Webhook node, n8n rejects any request whose token does not match and never creates an execution, which is exactly why your PowerShell call with the right credential works, Google Chat does not, and Google logs “didn’t respond or its response was invalid”.
Set the Webhook node’s Authentication to None and republish; Google’s requests will then reach the workflow and log executions. To stay secure without n8n-level auth, verify Google’s JWT inside the workflow instead: a Code node checking the issuer chat@system.gserviceaccount.com and the audience (your app’s project number or endpoint URL), dropping anything that fails.
On your two questions: n8n Cloud is not selectively blocking Google’s servers here, and pre-execution edge logs are not exposed to users, so that is a support-only view. You do not need them, since switching auth off and re-testing confirms the cause in one step.
Once delivery works, make sure the Respond to Webhook node returns valid Chat JSON like {"text":"..."} quickly, so you do not trip code 3 for a genuinely invalid response.
Verify requests from Google Chat  |  Google for Developers

3

Good diagnosis from @Anshul_Namdev — the auth mismatch is exactly why your manual PowerShell call creates an execution but Google Chat never does. Google signs every request with its own Bearer JWT, so any Header/Basic/JWT auth on the Webhook node rejects it before an execution is ever created.

The piece worth adding: once you set the Webhook node Authentication to “None” to let Chat through, you don’t want the endpoint left wide open. Validate Google’s own token inside the flow instead. Drop a Code (or IF) node right after the Webhook and check the incoming Authorization Bearer JWT:

  • the issuer (iss) must be Google’s Chat system service account (chat@system.gserviceaccount, the one that signs Chat requests)
  • the audience (aud) must equal your Chat app’s numeric project number
  • verify the signature against Google’s published x509 certs for that same service account

If any check fails, stop the workflow. Only authentic Google Chat traffic carries a token that passes, so the Webhook node stays open (Chat’s requests finally create executions) while random callers get filtered out. That gives you the same protection the node auth was trying to provide, without blocking the very sender you want.

4

Same symptom here on self-hosted n8n 2.2.4, and the auth explanation doesn’t fit my case.

Issue

  • POST to my production webhook URL manually (curl, PowerShell) works: execution appears, runs, returns the expected response. HTTP 200.
  • Google Chat sends to that same URL and no execution is created. Every execution that webhook has ever had has user-agent curl/8.5.0 or PowerShell. No Google-originated request has ever appeared, including a failed one.
  • Google Cloud Logging: code 13, “Due to an internal error, Chat failed to process the bot response”, 18 entries.
  • Webhook node auth is not the cause. My manual POSTs send no Authorization header at all and still return 200, so the node is not enforcing a credential. The workflow doesn’t set authentication — the node is just:

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

typeVersion: 2, no authentication key. Respond to Webhook is respondWith: json returning the hostAppDataAction.chatDataAction.createMessageAction envelope.

Already checked

  • Endpoint URL verified character-for-character in the Chat API console, /webhook/ not /webhook-test/.
  • “Build as a Workspace add-on” checked, app status LIVE, interactive features on, common HTTP endpoint URL for all triggers.
  • Three from-scratch rebuilds of the Chat app in three new Google Cloud projects. Same result each time.

Questions

  1. On self-hosted n8n, where does a request that reaches the process but never creates an execution appear? Does N8N_LOG_LEVEL=debug log a POST to an unregistered path, or is there another way to confirm arrival? Distinguishing “Google never sent it” from “n8n dropped it before execution” is the blocker.
  2. Can a production webhook path fail to register while the workflow is active and the URL returns 200 to manual calls — after an import, or a duplicated workflow? This one was imported via the REST API and carries a human-readable webhookId string rather than a UUID.
  3. In the Chat API console, the Service Account Email field does not render at all for this app — absent, not blank, and no gsuiteaddons string anywhere in the page. Has anyone seen that, and does it indicate the add-on deployment never registered a dispatch target?
5

Since @JGCoder has confirmed that the Webhook node uses no authentication and a manual unauthenticated POST works, I would split the diagnosis before changing JWT settings:

  1. Check the reverse-proxy/ingress access log while sending a Google Chat test event. If no Google-origin request appears, the failure is upstream of n8n: verify the Chat app’s exact production URL, POST method, deployment/availability, and test-user access.
  2. If the request appears with 30x or 403, fix the redirect, WAF, or TLS/proxy rule.
  3. If it reaches n8n but creates no execution, verify the published webhook registration plus the exact path and method.

For one test, reduce the workflow to Webhook (POST, production URL) -> Respond to Webhook and return HTTP 200 within a few seconds with {"text":"ok"}. Then compare the URL and status shown in Google Cloud Logging with the proxy log. That identifies whether the fault is Google Chat delivery, the edge/proxy, or n8n itself.