Connect n8n to OpenClaw: trigger an agent through a webhook

Use the agent webhook, not an internal hook

OpenClaw has three similarly named features. Internal hooks run code when Gateway events happen. The Webhooks plugin manages TaskFlow records. 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 September 16, 2026, we ran an n8n Cloud HTTP Request step against OpenClaw 2026.9.1 and received the agent’s answer in Telegram. The same request was accepted again after a container restart. The HTTP configuration worked; most of the setup time went into an older-version approval failure and making the token available to the correct process.

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. In our test, putting a value in the agent’s secret-store environment made it available to agent commands but not to the Gateway. The configuration applied, yet hooks stayed unavailable until the Gateway itself could 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; those two editors were not part of our test.

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. During our setup, a browser GET returned an HTML shell while a POST showed that hooks were 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.