Connect n8n to OpenClaw: trigger an agent through a webhook

Use the agent webhook, not an internal hook

OpenClaw has had three similarly named features. Internal hooks run code when Gateway events happen. A Webhooks plugin managed TaskFlow records until OpenClaw 2026.9.7 removed both. The Gateway’s inbound HTTP hooks accept a request from an outside service and can start an agent turn. That last feature is the one this workflow uses.

On OpenClaw 2026.9.1 (September 2026), an n8n Cloud HTTP Request step starts an agent turn whose answer arrives in Telegram, and the same saved request is accepted again after a container restart. The request itself is the simple part. What can stop the setup is a cancelled setup approval on that version, and a token the Gateway’s own process cannot read.

Prepare OpenClaw

Start with an agent that already answers you in Telegram. Enable HTTP hooks for that agent and create a long, random token used only for this integration. The relevant configuration is:

{
  "hooks": {
    "enabled": true,
    "token": "<dedicated-hook-token>",
    "path": "/hooks",
    "allowedAgentIds": ["main"],
    "allowRequestSessionKey": false
  }
}

Merge that block into your existing configuration; do not replace the whole file. Use your actual agent ID if it is not main. Validate with openclaw config validate and restart the Gateway through its normal supervisor to load the change.

The hook-token contract is unusually important here: the token is a string, not a SecretRef object. Environment substitution must resolve in the Gateway’s environment. On 2026.9.1, a value placed in the agent’s secret-store environment reaches agent commands but not the Gateway: the configuration applies, yet hooks stay unavailable until the Gateway itself can resolve the variable. Keep the token out of ordinary chat and workflow logs.

Configure the n8n request

Connect a manual trigger to an HTTP Request node for the first test. Configure:

• Method: POST.
• URL: https://your-webhook-host.example/hooks/agent, replaced with the real reachable address.
• Authentication: a stored Header Auth credential whose name is Authorization and value is Bearer <your-hook-token>.
• Body: JSON, sent with Content-Type: application/json.

{
  "message": "Confirm that this workflow reached you.",
  "name": "n8n test",
  "agentId": "main",
  "deliver": true,
  "channel": "telegram",
  "to": "<your-Telegram-chat-id>"
}

Use the intended Telegram chat’s numeric ID, not the bot’s username. Start with that fixed destination before mapping fields from incoming events. In Zapier or Make, configure the equivalent HTTP action with the same method, header and JSON body; these steps are established on n8n’s HTTP Request node, so in those editors the first reply in Telegram is what confirms them.

When the agent has no public port

A machine behind NAT can receive a webhook through a tunnel or a managed public endpoint. The connection must reach the hook route with its authentication header intact. Keep the public URL stable across restarts so the saved workflow continues to call the same address. Do not expose the whole control panel just to expose one integration route.

An address that opens a web page is not a webhook test: a browser GET can return an HTML shell while a POST to the same address shows that hooks are still off. Test the actual method, path, token and payload that the workflow will send.

A successful request is not yet a reply

The default response reports admission and a runId, not the answer text. Confirm receipt in Telegram. If there is no message, inspect that run and check its destination and delivery outcome before adding automatic retries.

A 401 points at hook authentication; a 404 can mean the hook route is disabled or wrong. A cancelled setup approval on 2026.9.1 is a separate failure with a released fix. Once the test works, replace the manual trigger with your real event and keep external content treated as data. Sending an event to an agent does not remove that agent’s tools or access.