Telegram webhook returns 403 Forbidden for external requests while "Listen for test event" works correctly

[Bhagyashah05]

Bug Description

Telegram Trigger node's production webhook works when manually triggered via "Listen for test event" in the editor, but real external requests sent by Telegram to the same production URL are rejected with 403 Forbidden before the workflow executes. Confirmed via Telegram's getWebhookInfo API that Telegram is successfully reaching the URL — the request arrives, it's just rejected. The ip_address field returned by getWebhookInfo has changed between checks (172.67.72.185, then 104.26.13.13) — both resolve to Cloudflare — suggesting the rejection may be happening at a proxy/edge layer in front of the instance rather than in the workflow itself. This appears to match a previously reported issue, n8n-io/n8n #20977 ("Return 403 Forbidden for external requests"), which describes the same test-works/production-fails pattern.

To Reproduce

Create a workflow with a Telegram Trigger node as the only entry point, listening for message and callback_query updates.
Set the workflow to Active.
In the editor, click the Telegram Trigger node and select "Listen for test event," then send a message to the bot — this succeeds and the workflow executes correctly.
Send a message to the same bot normally (outside the editor, real external Telegram traffic hitting the production webhook URL).
Check https://api.telegram.org/bot/getWebhookInfo — last_error_message shows Wrong response from the webhook: 403 Forbidden, and the workflow does not execute.
Already tried without resolution: confirming the workflow is Active, toggling it off/on to force webhook re-registration, and recreating the Telegram Trigger node to get a fresh webhook path.

Expected behavior

Real external Telegram requests to the production webhook URL should be accepted and trigger the workflow the same way "Listen for test event" does in the editor.

Debug Info

n8nVersion: 2.30.4
platform: docker (cloud)
nodeJsVersion: 24.16.0
nodeEnv: production
database: sqlite
executionMode: regular
concurrency: 5
license: enterprise (sandbox)
success: all
error: all
progress: false
manual: true
binaryMode: filesystem
pruning enabled: true
maxAge: 168 hours
maxCount: 2500 executions
userAgent: mozilla/5.0 (macintosh; intel mac os x 10_15_7) applewebkit/537.36 (khtml, like gecko) chrome/147.0.0.0 safari/537.36
Generated at: 2026-07-15T07:51:06.433Z

Operating System

Operating System: N/A — n8n Cloud (managed hosting, underlying OS not exposed to the user)

n8n Version

n8n Version: 2.30.4

Node.js Version

Node.js Version: 24.16.0

Database

SQLite (default)

Execution mode

main (default)

Hosting

n8n cloud

[n8n-assistant]

Hey @Bhagyashah05,

Thank you for reaching out! We’ve received your issue and are looking into it. To help us track this internally, we’ve created a Linear ticket with the reference: "GHC-8953".

We’ll keep you updated as we make progress, but if you have any additional details or context to share, feel free to add them here - it’s always helpful!

Thanks for your patience and for bringing this to our attention.

---

For INTERNAL use only: GHC-8953

[IgorGanapolsky]

Reliability note

Production automation failures usually reduce to a contract issue before a model/prompt issue:

1. Success criteria — durable artifact id (message/booking/row), not only node green
2. Side-effect before complete — never blind-retry without an idempotency key on the business object
3. Tool vs path split — external action can succeed while the node/agent path still errors (silent-green / false-red)

If you have one failing execution + expected vs actual, reply with stack/version and I will send a free root-cause checklist.