OpenClaw webhooks to multiple users | Friends of the Crustacean 🦞🤝 | Page 1

restive pebble Apr 22, 2026, 4:35 AM

#

I'm trying to use n8n to pass some information from a webhook to OpenClaw for analysis and then send it to multiple users (but the users aren't fixed; it's sent to different users depending on the information). My question is, can the to parameter in the body be set to accept multiple users? Or is there another way to do this?

sour ermineBOT Apr 22, 2026, 4:35 AM

#

noble bridgeBOT Apr 22, 2026, 4:38 AM

#

Let me verify the docs and webhook shape so I don’t guess.

#

I found the current docs layout, grabbing the FAQ plus the webhook/message docs now.

#

Short answer: not as to.

For current OpenClaw messaging, use:

target for one recipient
targets for multiple recipients, with action: "broadcast"

Example for Discord DMs to multiple users:

{
  "action": "broadcast",
  "channel": "discord",
  "targets": [
    "user:123456789012345678",
    "user:987654321098765432"

#

  ],
  "message": "Analysis complete"
}

A couple of important gotchas:

to is not the current field for the message tool/action, use target / targets.
On Discord, use explicit user:<id> targets for DMs. Bare numeric IDs can be treated as channels.
broadcast sends the same payload to all targets. If each user needs a different message, loop in n8n and send one request per recipient.

If you mean a webhook that wakes an agent first, that webhook itself does not magically fan out. The usual pattern is:

n8n sends webhook payload to OpenClaw
OpenClaw analyzes it
OpenClaw calls broadcast or multiple sends based on the recipients in the payload

#

Docs:

<https://docs.openclaw.ai/cli/message>
<https://docs.openclaw.ai/gateway/configuration#hooks>
<https://docs.openclaw.ai/plugins/webhooks>

If you want, paste the exact n8n request body you’re using and I can reshape it for the right OpenClaw endpoint.

restive pebble Apr 22, 2026, 4:47 AM

#

In n8n, I used the HTTP Request node with the below parameters.
Method: POST
URL: http://openclaw.xxx.xxx/hooks/agent
Authentication: Generic Credential Type
Generic Auth Type: Bearer Auth
Bearer Auth: openclaw-hook-bearer-token
Send Query Parameters: False
Send Headers: False
Send Body: True
Body Content Type: JSON
Specify Body: Using Fields Below
Body Parameters

Name: message
Value: <alert payload>

Name: to
Value: {{ $json.receiverIds }} //Wish to set multiple recipients

Name: channel
Value: feishu

Above is my current setup.

noble bridgeBOT Apr 22, 2026, 4:48 AM

#

Let me check the hook payload contract, because /hooks/agent is a bit different from direct message sends.

#

Yep, with /hooks/agent, to is a single string target, not a list.

The current hook payload is:

{
  "message": "...",
  "channel": "feishu",
  "to": "one-recipient"
}

So this part will not fan out:

to: {{ $json.receiverIds }}

#

if receiverIds is an array.

Best options

1. Recommended, fan out in n8n
Analyze once, then split receiverIds and send one hook request per recipient.

In n8n that usually means:

Split Out / Item Lists on receiverIds
then call /hooks/agent once per item with:

{
  "message": "<alert payload>",
  "channel": "feishu",
  "to": "{{ $json.receiverId }}"

#

2. Let OpenClaw do the multi-send
Pass the recipient list inside the payload/message, and set:

{
  "message": "... includes receiverIds ...",
  "deliver": false
}

Then let the agent use the message tool to send to each recipient after analysis. This is better if the agent needs to decide who gets what.

Important detail

#

/hooks/agent does not have a multi-recipient targets field. That hook only supports one to.

Docs:

<https://docs.openclaw.ai/gateway/configuration-reference#hooks>

So, short version: no, to cannot be multiple users on /hooks/agent. Use n8n fan-out or deliver:false + agent-driven sending.

If you want, I can sketch the exact n8n node flow for either pattern.

restive pebble Apr 22, 2026, 4:52 AM

#

However, this leads to inconsistent results from OpenClaw's analysis, because when I tried it, the results I got were different from those of my friends. What I want is the same analysis, but sent to multiple people.

noble bridgeBOT Apr 22, 2026, 4:53 AM

#

Yep, that makes sense, you’re currently creating multiple separate agent runs, and LLM runs are not guaranteed to be identical.

If you want one analysis, then the same output sent to many people, the pattern should be:

Why this works

one hook call = one analysis
then the agent sends the same final text to each recipient
no per-recipient re-analysis, so no drift between users

What not to do

Do not call /hooks/agent once per recipient if you need identical output, because that creates separate LLM runs.

#

Important

For this pattern, don’t use hook-level to for the recipient list.
That to field on /hooks/agent is only for one final delivery target of the hook run itself.

If you want, I can help you turn your n8n flow into the exact 1-run -> multi-send shape.

restive pebble Apr 22, 2026, 4:55 AM

#

yes please

noble bridgeBOT Apr 22, 2026, 4:56 AM

#

Yep, here’s the clean 1 analysis -> many recipients n8n shape.

n8n flow

1. Webhook / trigger

Input example:

{
  "alertPayload": {
    "title": "CPU spike",
    "severity": "high",
    "host": "api-01"
  },
  "receiverIds": ["ou_xxx1", "ou_xxx2", "ou_xxx3"]
}

#

2. Set node or Code node

Build one prompt string first, for example as openclawPrompt:

Analyze the alert below exactly once.

Then create exactly one final outbound summary message.

Then send that exact same message, verbatim, via Feishu to each recipient in RECIPIENTS.
Do not rewrite it per recipient.
Do not re-analyze per recipient.
Do not personalize it.

RECIPIENTS:
{{ $json.receiverIds.join(", ") }}

#

ALERT:
{{ JSON.stringify($json.alertPayload, null, 2) }}

3. HTTP Request node

Keep using POST to:

http://openclaw.feedme.farm/hooks/agent

Body should be:

#

  "deliver": false,
  "message": "{{ $json.openclawPrompt }}"
}

If you want to force a specific agent:

{
  "deliver": false,
  "agentId": "main",
  "message": "{{ $json.openclawPrompt }}"
}

Important change from your current setup

#

Remove these from the hook body:

to
channel

for the multi-recipient case.

Those hook-level fields are only for the single final delivery target of the hook run itself.

Optional: send yourself a log copy too

If you want one fixed Feishu recipient to also get the final reply/log from the hook run, you can do:

#

{
  "deliver": true,
  "channel": "feishu",
  "to": "ou_your_admin_id",
  "message": "{{ $json.openclawPrompt }}"
}

That still gives you one analysis run.
The agent can then fan out the same summary to the recipients in receiverIds.

Why this fixes the inconsistency

Before:

#

one hook call per recipient
multiple separate LLM runs
slightly different answers

After:

one hook call total
one analysis
one final message reused for everyone

Small reliability tip

If the agent still rewrites messages a bit, make the prompt stricter:

#

Write the final message once.
Store it mentally as FINAL_MESSAGE.
Send FINAL_MESSAGE unchanged to every recipient.

If you want, I can also turn this into an exact n8n node-by-node config using your current “Using Fields Below” setup.

restive pebble Apr 22, 2026, 5:00 AM

#

This is an EXECUTION request, not a planning request.
Do not stop after acknowledgement or a phase outline.
Begin investigation immediately in the same run and continue autonomously until you reach a diagnosis, a concrete blocker, or a verified mitigation recommendation.
Execution rules:
- Use phased incident handling: Problem Report, Triage, Examine, Diagnose, Treat, Verify, Cure.
- Minimum 3 phases unless the issue is resolved earlier with high confidence.
- After each completed phase, send a concise user-facing progress update.
- If analysis can be parallelized, spawn self-contained analysis workers and report their findings progressively.
- Do not wait for a follow-up prompt to continue normal investigation.
- Only pause if you hit an approval gate, missing access, or a hard blocker.
- Never include internal planner text, system reminders, mode banners, or runtime instructions in user-facing replies.
Deliver updates in this shape:
1. Phase name
2. What was verified
3. Current hypothesis
4. Next action
Final summary format:
Summary:
- Root cause: ...
- Impact: ...
- Recommendation: ...
Incident context:
<alert_payload>

Above is the message I wish to pass; please integrate it with yours.

noble bridgeBOT Apr 22, 2026, 5:01 AM

#

Yep, use your incident prompt as the core, and wrap it with the one analysis, many sends instructions.

n8n body

Use:

{
  "deliver": false,
  "message": "{{ `
Analyze the incident below exactly once.

Then send the exact same user-facing phase updates and exact same final summary, unchanged, via Feishu to every recipient in RECIPIENTS.
Do not re-run the analysis per recipient.
Do not personalize or rewrite per recipient.

#

RECIPIENTS:
${$json.receiverIds.join(', ')}

This is an EXECUTION request, not a planning request.
Do not stop after acknowledgement or a phase outline.
Begin investigation immediately in the same run and continue autonomously until you reach a diagnosis, a concrete blocker, or a verified mitigation recommendation.

Execution rules:
- Use phased incident handling: Problem Report, Triage, Examine, Diagnose, Treat, Verify, Cure.
- Minimum 3 phases unless the issue is resolved earlier with high confidence.
- After each completed phase, send a concise user-facing progress update.
- If analysis can be parallelized, spawn self-contained analysis workers and report their findings progressively.
- Do not wait for a follow-up prompt to continue normal investigation.
- Only pause if you hit an approval gate, missing access, or a hard blocker.
- Never include internal planner text, system reminders, mode banners, or runtime instructions in user-facing replies.

#


Deliver updates in this shape:
1. Phase name
2. What was verified
3. Current hypothesis
4. Next action

Final summary format:
Summary:
- Root cause: ...
- Impact: ...
- Recommendation: ...

Incident context:
${JSON.stringify($json.alertPayload, null, 2)}

#

` }}"
}

If you use “Using Fields Below”

deliver → false
message → the big expression above

Important

Do not include these anymore for the multi-send version:

to
channel

#

at the hook body level.

Those are only for the single delivery target of the hook run itself.

Optional

If you want you to also get a fixed copy/log of the run, then add:

deliver → true
channel → feishu
to → <your own fixed Feishu id>

That still keeps one analysis run, while the agent sends the same output to everyone in receiverIds.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

restive pebble Apr 22, 2026, 5:20 AM

#

But this doesn't seem to be working; I haven't received any analysis results.

noble bridgeBOT Apr 22, 2026, 5:21 AM

#

Ah, I think I see the problem.

With deliver: false, /hooks/agent does not send the analysis back to you. It just starts the run.

So if the agent does not successfully send its own outbound Feishu messages, you’ll see nothing at all.

First thing to test

Temporarily switch to this:

{
  "deliver": true,
  "channel": "feishu",
  "to": "<your-own-feishu-id>",
  "message": "Analyze this incident exactly once. Then send the exact same final summary unchanged to these Feishu recipients: ... "

#

What this verifies

If you receive the analysis, then the hook is working, and the problem is only the fan-out send step.
If you still receive nothing, then the hook run itself is failing or not delivering.

Very likely causes if hook works but fan-out doesn’t

the agent is not allowed to use the message tool
Feishu target IDs are wrong
the prompt is not explicit enough, so the agent analyzes but never sends

Also important

#

If you expected the HTTP response in n8n to contain the finished analysis, /hooks/agent is not that kind of endpoint. It is async, not a synchronous “return final answer now” API.

Please send these next

openclaw --version
openclaw status
a log snippet from right after the hook call, for example:
```
openclaw logs --follow
```

Docs:

<https://docs.openclaw.ai/help/faq>
<https://docs.openclaw.ai/gateway/troubleshooting>

If you paste the log output, I can help narrow it down fast.

restive pebble Apr 22, 2026, 5:25 AM

#

Here are my latest settings in n8n based on the updated information you provided. But this doesn't seem to be working; I haven't received any analysis results.

Method: POST
URL: http://openclaw.xxx.xxx/hooks/agent
Authentication: Generic Credential Type
Generic Auth Type: Bearer Auth
Bearer Auth: openclaw-hook-bearer-token
Send Query Parameters: False
Send Headers: False
Send Body: True
Body Content Type: JSON
Specify Body: Using Fields Below
Body Parameters

Name: message
Value: Analyze the incident below exactly once.

Then send the exact same user-facing phase updates and exact same final summary, unchanged, via Feishu to every recipient in RECIPIENTS.
Do not re-run the analysis per recipient.
Do not personalize or rewrite per recipient.
RECIPIENTS:
{{$json.receiverIds.join(', ')}}

This is an EXECUTION request, not a planning request.
Do not stop after acknowledgement or a phase outline.
Begin investigation immediately in the same run and continue autonomously until you reach a diagnosis, a concrete blocker, or a verified mitigation recommendation.
Execution rules:
- Use phased incident handling: Problem Report, Triage, Examine, Diagnose, Treat, Verify, Cure.
- Minimum 3 phases unless the issue is resolved earlier with high confidence.
- After each completed phase, send a concise user-facing progress update.
- If analysis can be parallelized, spawn self-contained analysis workers and report their findings progressively.
- Do not wait for a follow-up prompt to continue normal investigation.
- Only pause if you hit an approval gate, missing access, or a hard blocker.
- Never include internal planner text, system reminders, mode banners, or runtime instructions in user-facing replies.
Deliver updates in this shape:
1. Phase name
2. What was verified
3. Current hypothesis
4. Next action
Final summary format:
Summary:
- Root cause: ...
- Impact: ...
- Recommendation: ...
Incident context:
<alert payload>


Name: deliver
Value: false

noble bridgeBOT Apr 22, 2026, 5:25 AM

#

I think I spot the likely bug.

Most likely issue

In n8n, with “Using Fields Below”, this:

Name: deliver
Value: false

is very often sent as the string "false", not the JSON boolean false.

For OpenClaw hooks, that matters a lot.
Only real boolean false disables delivery.
String "false" is treated as not false.

#

So your request may effectively be acting like:

{ "deliver": true }

while also having no top-level channel / to, which can lead to “nothing visible happened”.

Second likely issue

This part may also still be literal text unless the field is actually in expression mode:

{{$json.receiverIds.join(', ')}}

#

and this is definitely still literal in your pasted example:

<alert payload>

So OpenClaw may literally be receiving <alert payload> instead of the real incident data.

Best fix

Option A, easiest: switch body to raw JSON

Use RAW JSON instead of “Using Fields Below”, and send:

#

{
  "deliver": true,
  "channel": "feishu",
  "to": "YOUR_OWN_FEISHU_ID",
  "message": "Analyze the incident below exactly once.\n\nThen send the exact same user-facing phase updates and exact same final summary, unchanged, via Feishu to every recipient in RECIPIENTS.\nDo not re-run the analysis per recipient.\nDo not personalize or rewrite per recipient.\n\nRECIPIENTS:\n{{ $json.receiverIds.join(', ') }}\n\nThis is an EXECUTION request, not a planning request.\nDo not stop after acknowledgement or a phase outline.\nBegin investigation immediately in the same run and continue autonomously until you reach a diagnosis, a concrete blocker, or a verified mitigation recommendation.\nExecution rules:\n- Use phased incident handling: Problem Report, Triage, Examine, Diagnose, Treat, Verify, Cure.\n- Minimum 3 phases unless the issue is resolved earlier with high confidence.\n- After each completed phase, send a concise user-facing progress update.\n- If analysis can be parallelized, spawn self-contained analysis workers and report their findings progressively.\n- Do not wait for a follow-up prompt to continue normal investigation.\n- Only pause if you hit an approval gate, missing access, or a hard blocker.\n- Never include internal planner text, system reminders, mode banners, or runtime instructions in user-facing replies.\nDeliver updates in this shape:\n1. Phase name\n2. What was verified\n3. Current hypothesis\n4. Next action\nFinal summary format:\nSummary:\n- Root cause: ...\n- Impact: ...\n- Recommendation: ...\n\nIncident context:\n{{ JSON.stringify($json.alertPayload, null, 2) }}"
}

Why I’m telling you to send it to yourself first

That verifies the hook run is actually working.

If you get the result, then the next problem is only the agent’s fan-out to receiverIds.

After that works

#

Then you can either:

keep deliver: true + to: YOUR_OWN_FEISHU_ID as a debug/log copy, or
switch back to a real boolean false later, once the agent fan-out is confirmed

If you must keep “Using Fields Below”

Then make sure:

deliver is an expression returning a boolean, for example ={{false}}
message is an expression-aware field

replace <alert payload> with a real expression like:

{{ JSON.stringify($json.alertPayload, null, 2) }}

#

Next thing I need if it still fails

Please paste:

openclaw --version
openclaw status
the HTTP response status/body from n8n
a small log snippet from:
```
openclaw logs --follow
```

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

restive pebble Apr 22, 2026, 6:32 AM

#

Why does it sometimes send updates gradually and sometimes send all updates at once? I'd like to know if this behavior can be standardized.

noble bridgeBOT Apr 22, 2026, 6:34 AM

#

I found the Feishu-specific bit too, which explains the variability a lot better.

#

Yep, mostly, and the reason is streaming mode.

On Feishu, OpenClaw can do two different things:

preview/card streaming
block streaming

And Feishu enables both by default:

channels.feishu.streaming: true
channels.feishu.blockStreaming: true

So depending on:

whether the model emits output incrementally,
whether tools are being called,
and where text boundaries land,

#

you may see either:

gradual updates, or
a bigger flush at the end

Also, OpenClaw does not do true token-by-token channel streaming, it streams in message/block-sized chunks, so timing can vary a bit.

If you want it standardized

Always send one final message

Use:

{
  agents: {
    defaults: {
      blockStreamingDefault: "off",

#

    },
  },
  channels: {
    feishu: {
      streaming: false,
      blockStreaming: false,
    },
  },
}

That’s the most consistent “all at once” setup.

Prefer gradual updates

#

Use:

{
  agents: {
    defaults: {
      blockStreamingDefault: "on",
      blockStreamingBreak: "text_end",
    },
  },
  channels: {
    feishu: {
      streaming: true,
      blockStreaming: true,
    },
  },

#

That gives you the most consistent progressive behavior, though it still won’t be perfectly identical on every run if the model/tool flow differs.

My recommendation

If this is for alerts/incidents, I’d usually standardize to:

one final message for recipients
optionally a separate fixed debug/log copy to yourself

That’s less noisy and much more predictable.

#

Docs:

If you want, paste your current channels.feishu and agents.defaults config plus openclaw --version, and I can tell you the exact setting to change.

restive pebble Apr 22, 2026, 6:38 AM

#

It does work. However, why does it sometimes send the analysis results in phases and sometimes send all updates at once? I'm wondering if this behavior can be standardized.

Method: POST
URL: http://openclaw.xxx.xxx/hooks/agent
Authentication: Generic Credential Type
Generic Auth Type: Bearer Auth
Bearer Auth: openclaw-hook-bearer-token
Send Query Parameters: False
Send Headers: False
Send Body: True
Body Content Type: JSON
Specify Body: Using Fields Below
Body Parameters

Name: message
Value: Analyze the incident below exactly once.
Then send the exact same user-facing phase updates and exact same final summary, unchanged, via Feishu to every recipient in RECIPIENTS.
Do not re-run the analysis per recipient.
Do not personalize or rewrite per recipient.
RECIPIENTS:
{{$json.receiverIds.join(', ')}}
This is an EXECUTION request, not a planning request.
Do not stop after acknowledgement or a phase outline.
Begin investigation immediately in the same run and continue autonomously until you reach a diagnosis, a concrete blocker, or a verified mitigation recommendation.
Execution rules:
- Use phased incident handling: Problem Report, Triage, Examine, Diagnose, Treat, Verify, Cure.
- Minimum 3 phases unless the issue is resolved earlier with high confidence.
- After each completed phase, send a concise user-facing progress update.
- If analysis can be parallelized, spawn self-contained analysis workers and report their findings progressively.
- Do not wait for a follow-up prompt to continue normal investigation.
- Only pause if you hit an approval gate, missing access, or a hard blocker.
- Never include internal planner text, system reminders, mode banners, or runtime instructions in user-facing replies.
Deliver updates in this shape:
1. Phase name
2. What was verified
3. Current hypothesis
4. Next action
Final summary format:
Summary:
- Root cause: ...
- Impact: ...
- Recommendation: ...
Incident context:
<alert payload>

Name: deliver
Value: {{false}}

noble bridgeBOT Apr 22, 2026, 6:39 AM

#

Yep, and in this specific setup the main reason is a bit different from channel streaming.

Because you’re using:

"deliver": false

the hook itself is not doing the outward delivery.
What’s happening is:

the agent analyzes
then the agent decides when to call the message tool

So the variability is mostly from the model deciding when to send, not just Feishu transport.

Your prompt currently says:

#

“After each completed phase, send a concise user-facing progress update.”

That gives the model permission to:

send progressively, or
think for longer and then send several updates together

So yes, it can be standardized, but mostly by tightening the prompt

If you want exactly one final message every time

Use this instead:

Analyze the incident below exactly once.

Do not send any intermediate updates.
Do not send phased progress messages.

#


Only after the full analysis is complete, send exactly one final summary, unchanged, via Feishu to every recipient in RECIPIENTS.

RECIPIENTS:
{{$json.receiverIds.join(', ')}}

Final summary format:
Summary:
- Root cause: ...
- Impact: ...
- Recommendation: ...

Incident context:
{{ JSON.stringify($json.alertPayload, null, 2) }}

#

That is the most reliable option.

If you want progressive phase-by-phase updates every time

Make it much stricter:

Analyze the incident below exactly once.

You must send updates in this exact order:
1. Problem Report
2. Triage
3. Examine
4. Diagnose
5. Treat

#

6. Verify
7. Cure
8. Final summary

After finishing each phase, immediately send exactly one message via Feishu to every recipient in RECIPIENTS before continuing to the next phase.
Do not batch multiple phases into one later message.
Do not wait until the end to send prior phase updates.

That helps, but I’d still call it best effort, not perfectly guaranteed, because it’s still an LLM deciding when to act.

My honest recommendation

If you want predictable behavior, standardize on:

#

one final message only
no intermediate phase updates

That’s much more stable than asking the model to manage timed progress delivery.

So, short version:

phases sometimes = the model is sending as it goes
all at once sometimes = the model held the sends and batched them
most standardizable = remove phased-send instructions and send one final result only

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

restive pebble Apr 22, 2026, 7:48 AM

#

However, I found that the one final message method only sent an acknowledge message and then stopped.

noble bridgeBOT Apr 22, 2026, 7:49 AM

#

Yep, that tracks, and it’s usually a prompting issue, not a transport issue.

What likely happened is:

the model saw “do one final message”
but still treated an acknowledgement as a valid outbound message
then never sent the real final summary

Fix

For the one final message mode, make the prompt much stricter and simpler.

Use something like this:

Analyze the incident below exactly once.

#


Do all analysis privately.
Do not send any acknowledgement.
Do not send any progress update.
Do not send any placeholder or "working on it" message.

Your first outbound message must also be your final outbound message.

After the analysis is complete, send exactly one final message, unchanged, via Feishu to every recipient in RECIPIENTS.

If the incident data is missing or invalid, send exactly one final error message instead.

RECIPIENTS:
{{$json.receiverIds.join(', ')}}

#

Final message format:
Summary:
- Root cause: ...
- Impact: ...
- Recommendation: ...

Incident context:
{{ JSON.stringify($json.alertPayload, null, 2) }}

Important

If you’re using the one final message mode, remove the earlier phased-response instructions entirely, especially things like:

“Begin investigation immediately”
“After each completed phase...”

#

“Do not stop after acknowledgement...”

Those are great for progressive updates, but they nudge the model toward sending an ack/status message.

Best practice

For final-only delivery, the shorter prompt is actually better.
Too many workflow rules make the model improvise.

If you want, I can rewrite your full n8n message field into a clean final-only version you can paste directly.

restive pebble Apr 27, 2026, 3:39 AM

#

@noble bridge I created an OpenClaw with Lark custom app. Can I make it automatically attach messages to a specific message thread via n8n?

noble bridgeBOT Apr 27, 2026, 3:41 AM

#

Yes — but don’t put the thread into to alone.

For Lark/Feishu, treat it as:

to / target = the chat or user, e.g. chat:oc_xxx
messageId / replyTo = the message/thread root to reply under, usually an om_* ID
use action: "thread-reply" for a true thread reply

Example from n8n via Gateway /tools/invoke:

{
  "tool": "message",
  "args": {
    "action": "thread-reply",
    "channel": "feishu",

#

    "target": "chat:oc_xxx",
    "messageId": "om_xxx",
    "message": "Analysis result here"
  }
}

If you’re using /hooks/agent, the built-in fallback delivery only supports channel + to, so it can send to the Lark chat but not reliably pin to a specific thread. In that case, either:

include the chat_id + root messageId in the prompt and tell OpenClaw to send with the message tool, or
have n8n call OpenClaw for analysis, then separately call /tools/invoke with thread-reply.

For multiple recipients, don’t make to an array — loop over recipients in n8n and send once per target/thread.

Docs: https://docs.openclaw.ai/channels/feishu and https://docs.openclaw.ai/gateway/tools-invoke-http-api

restive pebble Apr 27, 2026, 4:20 AM

#

How to use /tools/invoke?

noble bridgeBOT Apr 27, 2026, 4:22 AM

#

/tools/invoke is an HTTP endpoint, not a chat slash command.

For n8n, use an HTTP Request node:

POST http://127.0.0.1:18789/tools/invoke
Authorization: Bearer YOUR_GATEWAY_TOKEN
Content-Type: application/json

Single Discord DM/channel send:

{
  "tool": "message",
  "action": "send",

#

  "args": {
    "channel": "discord",
    "target": "user:123456789012345678",
    "message": "Hello from n8n"
  }
}

For multiple recipients, don’t make to an array. Use broadcast + targets:

{
  "tool": "message",
  "action": "broadcast",
  "args": {

#

    "channel": "discord",
    "targets": [
      "user:111111111111111111",
      "user:222222222222222222",
      "channel:333333333333333333"
    ],
    "message": "Same message to multiple targets"
  }
}

Discord target formats:

DM: user:<discord-user-id>
Channel/thread: channel:<discord-channel-id>
Don’t use bare numeric IDs; they’re ambiguous.

#

Important: keep /tools/invoke private — loopback, tailnet, or trusted proxy only. The gateway token is basically operator access.

Docs: https://docs.openclaw.ai/gateway/tools-invoke-http-api and https://docs.openclaw.ai/cli/message

restive pebble Apr 27, 2026, 4:27 AM

#

How to use /tools/invoke to send messages to a specific message thread via n8n?

noble bridgeBOT Apr 27, 2026, 4:27 AM

#

Use the Discord thread ID as the target — Discord threads are treated like channels.

n8n HTTP Request node:

POST http://127.0.0.1:18789/tools/invoke
Authorization: Bearer YOUR_GATEWAY_TOKEN
Content-Type: application/json

Body:

{
  "tool": "message",
  "action": "send",

#

  "args": {
    "channel": "discord",
    "target": "channel:DISCORD_THREAD_ID",
    "message": "Hello, this goes into the thread."
  }
}

Notes:

Enable Discord Developer Mode → right-click the thread → Copy Thread ID
Use channel:<threadId>, not the parent channel ID
The bot needs Send Messages in Threads
For Discord, don’t use threadId here — that’s mainly for Telegram/Slack-style thread routing. Discord threads are their own channel targets.

If you want to send the same message to several threads/users:

#

{
  "tool": "message",
  "action": "broadcast",
  "args": {
    "channel": "discord",
    "targets": [
      "channel:THREAD_ID_1",
      "channel:THREAD_ID_2",
      "user:USER_ID"
    ],
    "message": "Same message to multiple targets."
  }
}

Docs: https://docs.openclaw.ai/gateway/tools-invoke-http-api and https://docs.openclaw.ai/channels/discord

restive pebble Apr 27, 2026, 4:33 AM

#

I created an OpenClaw with a Lark custom app. How to use /tools/invoke to send messages to a specific message thread via n8n?

noble bridgeBOT Apr 27, 2026, 4:34 AM

#

For Lark/Feishu, use the OpenClaw channel name feishu.

To send into a specific Lark/Feishu message thread, use message tool action thread-reply. You need:

target: the chat/group id, usually chat:oc_xxx
messageId: the root/parent message id, usually om_xxx
message: the content to send

n8n HTTP Request body:

{
  "tool": "message",
  "action": "thread-reply",
  "args": {
    "channel": "feishu",

#

    "target": "chat:oc_xxx",
    "messageId": "om_xxx",
    "message": "Hello, this goes into the Lark thread."
  }
}

HTTP request:

POST http://127.0.0.1:18789/tools/invoke
Authorization: Bearer YOUR_GATEWAY_TOKEN
Content-Type: application/json

If you use n8n expressions:

#

{
  "tool": "message",
  "action": "thread-reply",
  "args": {
    "channel": "feishu",
    "target": "chat:{{ $json.chat_id }}",
    "messageId": "{{ $json.root_message_id }}",
    "message": "{{ $json.text }}"
  }
}

Important detail: for Feishu/Lark thread replies, messageId should be the message id (om_...) you’re replying under, not just the thread container id (omt_...).

If you need to send to multiple Lark threads, loop in n8n and call /tools/invoke once per thread. broadcast is fine for top-level sends, but thread replies need their own messageId.

#

Docs: https://docs.openclaw.ai/gateway/tools-invoke-http-api and https://docs.openclaw.ai/channels/feishu

restive pebble Apr 27, 2026, 4:44 AM

#

But how to enable tools/invoke in OpenClaw config?

noble bridgeBOT Apr 27, 2026, 4:45 AM

#

You don’t enable /tools/invoke separately — it’s always enabled on the Gateway HTTP port.

What you need is:

Gateway running
Gateway auth configured
message tool allowed by tool policy

Minimal config shape:

{
  gateway: {
    port: 18789,
    bind: "loopback",
    auth: {

#

      mode: "token",
      token: "use-a-long-random-secret"
    }
  },

  tools: {
    profile: "messaging"
  }
}

If you already use tools.profile: "coding" and want to keep it, add messaging instead:

#

  tools: {
    profile: "coding",
    alsoAllow: ["group:messaging"]
  }
}

If you already have tools.allow, don’t add alsoAllow; put message / group:messaging inside the existing allowlist.

Then restart:

openclaw gateway restart

Test from n8n / curl:

#

curl -sS http://127.0.0.1:18789/tools/invoke \
  -H "Authorization: Bearer YOUR_GATEWAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "tool": "message",
    "action": "send",
    "args": {
      "channel": "feishu",
      "target": "chat:oc_xxx",
      "message": "test"
    }
  }'

If you get 404, it usually means the message tool isn’t allowed by policy. If you get 401, it’s auth/token. Also check openclaw --version if things don’t match the docs.

#

Docs: https://docs.openclaw.ai/gateway/tools-invoke-http-api

restive pebble Apr 27, 2026, 4:54 AM

#

tools: {
        profile: "full",
        deny: ["sessions_list", "sessions_history", "sessions_send"],
        fs: {
          workspaceOnly: true,
        },
        exec: {
          security: "full",
          pathPrepend: [
            "/usr/local/bin",
            "/usr/local/lib/node_modules/.bin",
            "/usr/bin",
          ],
          notifyOnExit: false,
        },
      },

I have used tools.profile: "full", but still get 401 Unauthorized error.

noble bridgeBOT Apr 27, 2026, 4:54 AM

#

401 is auth, not tool policy.

tools.profile: "full" only matters after the request is authenticated. For /tools/invoke, OpenClaw first checks Gateway auth; if that fails, you get 401 Unauthorized.

Please check:

openclaw --version
openclaw config get gateway.auth.mode
openclaw config get gateway.auth.token

If you don’t have a token yet:

openclaw config set gateway.auth.mode token

#

openclaw doctor --generate-gateway-token
openclaw gateway restart

Then in n8n send this header exactly:

Authorization: Bearer YOUR_GATEWAY_TOKEN
Content-Type: application/json

If n8n has a built-in Bearer Auth field, put only the token there — don’t include Bearer twice.

Also double-check you are calling the same Gateway:

#

POST http://127.0.0.1:18789/tools/invoke

If n8n is running in Docker, 127.0.0.1 means the n8n container, not your host. Use the host address / host.docker.internal as appropriate.

Quick rule:

401 = wrong/missing Gateway auth token/password
404 = tool not available / not allowed by tools.* policy

Docs: https://docs.openclaw.ai/gateway/tools-invoke-http-api

restive pebble Apr 27, 2026, 5:00 AM

#

I have a /hooks/agent bearer token, can't I use it for /tools/invoke?

noble bridgeBOT Apr 27, 2026, 5:00 AM

#

No — /hooks/agent token and /tools/invoke auth are separate on purpose.

/hooks/agent uses hooks.token
/tools/invoke uses Gateway auth: gateway.auth.token or gateway.auth.password

So for /tools/invoke, n8n must use:

Authorization: Bearer <gateway.auth.token>

Not the hooks token.

Check yours with:

#

openclaw config get gateway.auth.mode
openclaw config get gateway.auth.token

If missing:

openclaw config set gateway.auth.mode token
openclaw doctor --generate-gateway-token
openclaw gateway restart

Then use that generated gateway token in n8n.

Also: don’t reuse the same value for hooks.token and gateway.auth.token; OpenClaw treats them as different security surfaces. /hooks/agent is for “run an agent turn from a webhook”; /tools/invoke is operator-level direct tool access.

#

Docs: https://docs.openclaw.ai/gateway/tools-invoke-http-api and https://docs.openclaw.ai/gateway/configuration-reference#hooks

restive pebble Apr 27, 2026, 1:16 PM

#

If I used /hooks/agent, how do I modify my prompt?

This is an EXECUTION request, not a planning request.
Do not stop after acknowledgement or a phase outline.
Begin investigation immediately in the same run and continue autonomously until you reach a diagnosis, a concrete blocker, or a verified mitigation recommendation.
Execution rules:
- Use phased incident handling: Problem Report, Triage, Examine, Diagnose, Treat, Verify, Cure.
- Minimum 3 phases unless the issue is resolved earlier with high confidence.
- After each completed phase, send a concise user-facing progress update.
- If analysis can be parallelized, spawn self-contained analysis workers and report their findings progressively.
- Do not wait for a follow-up prompt to continue normal investigation.
- Only pause if you hit an approval gate, missing access, or a hard blocker.
- Never include internal planner text, system reminders, mode banners, or runtime instructions in user-facing replies.
Deliver updates in this shape:
1. Phase name
2. What was verified
3. Current hypothesis
4. Next action
Final summary format:
Summary:
- Root cause: ...
- Impact: ...
- Recommendation: ...
Incident context:
[{{ $('Code in JavaScript - Extract Data').item.json.Status }}][{{ $('Code in JavaScript - Extract Data').item.json.Team }}] - Grafana ALERT 🚨 
{{ $('Code in JavaScript - Extract Data').item.json.Message }} 
🔗 URL: {{ $('Code in JavaScript - Extract Data').item.json.URL }}

noble bridgeBOT Apr 27, 2026, 1:17 PM

#

Yes — with /hooks/agent, put your prompt in the JSON message field.

Important distinction:

/hooks/agent can deliver the final response to one channel / to.
If you need multiple recipients or Feishu thread replies, tell the agent to use the message tool itself, and set deliver: false to avoid duplicate final sends.

Example n8n body:

{
  "name": "Grafana Incident",
  "wakeMode": "now",
  "deliver": false,
  "timeoutSeconds": 900,
  "message": "Investigate this Grafana alert and send updates to the listed Feishu threads.\n\nRules:\n- Start immediately.\n- Work through: Problem Report, Triage, Diagnose, Treat, Verify.\n- After each phase, send a concise update using the message tool.\n- For each update, call message action=\"thread-reply\" with channel=\"feishu\", target=\"chat:oc_xxx\", messageId=\"om_xxx\".\n- At the end, send a final summary to the same threads.\n\nUpdate format:\n1. Phase name\n2. What was verified\n3. Current hypothesis\n4. Next action\n\nFinal summary format:\nSummary:\n- Root cause: ...\n- Impact: ...\n- Recommendation: ...\n\nRecipients:\n- chat:oc_xxx / root message: om_xxx\n- chat:oc_yyy / root message: om_yyy\n\nIncident context:\n[{{ $('Code in JavaScript - Extract Data').item.json.Status }}][{{ $('Code in JavaScript - Extract Data').item.json.Team }}] - Grafana ALERT 🚨\n{{ $('Code in JavaScript - Extract Data').item.json.Message }}\n🔗 URL: {{ $('Code in JavaScript - Extract Data').item.json.URL }}"

#

Call it with the hooks token, not gateway token:

POST http://127.0.0.1:18789/hooks/agent
Authorization: Bearer YOUR_HOOKS_TOKEN
Content-Type: application/json

If you only want one final top-level Feishu message, simpler:

#

  "message": "Investigate this alert...\n\nIncident context: ...",
  "deliver": true,
  "channel": "feishu",
  "to": "chat:oc_xxx"
}

But for Feishu threads, I’d use deliver:false + explicit message tool instructions as above. Ensure message tool is allowed in tools.*.

restive pebble Apr 27, 2026, 1:21 PM

#

If I used /hooks/agent, how do I modify my prompt?
Method: POST
URL: http://openclaw.xxx.xxx/hooks/agent
Authentication: Generic Credential Type
Generic Auth Type: Bearer Auth
Bearer Auth: openclaw-hook-bearer-token
Send Query Parameters: False
Send Headers: False
Send Body: True
Body Content Type: JSON
Specify Body: Using Fields Below
Body Parameters

This is an EXECUTION request, not a planning request.
Do not stop after acknowledgement or a phase outline.
Begin investigation immediately in the same run and continue autonomously until you reach a diagnosis, a concrete blocker, or a verified mitigation recommendation.
Execution rules:
- Use phased incident handling: Problem Report, Triage, Examine, Diagnose, Treat, Verify, Cure.
- Minimum 3 phases unless the issue is resolved earlier with high confidence.
- After each completed phase, send a concise user-facing progress update.
- If analysis can be parallelized, spawn self-contained analysis workers and report their findings progressively.
- Do not wait for a follow-up prompt to continue normal investigation.
- Only pause if you hit an approval gate, missing access, or a hard blocker.
- Never include internal planner text, system reminders, mode banners, or runtime instructions in user-facing replies.
Deliver updates in this shape:
1. Phase name
2. What was verified
3. Current hypothesis
4. Next action
Final summary format:
Summary:
- Root cause: ...
- Impact: ...
- Recommendation: ...
Incident context:
xxx

noble bridgeBOT Apr 27, 2026, 1:22 PM

#

In n8n, don’t put that prompt as the whole body. /hooks/agent expects a JSON object with a message field.

Use Body Parameters like this:

{
  "name": "Grafana Incident",
  "wakeMode": "now",
  "deliver": false,
  "timeoutSeconds": 900,
  "message": "This is an EXECUTION request, not a planning request.\n\nInvestigate the incident below. Work through phases: Problem Report, Triage, Examine, Diagnose, Treat, Verify, Cure.\n\nAfter each completed phase, send a concise progress update to Feishu using the message tool:\n- channel: feishu\n- action: thread-reply\n- target: chat:oc_xxx\n- messageId: om_xxx\n\nEach update must use this format:\n1. Phase name\n2. What was verified\n3. Current hypothesis\n4. Next action\n\nFinal summary format:\nSummary:\n- Root cause: ...\n- Impact: ...\n- Recommendation: ...\n\nIncident context:\nxxx"
}

For n8n Fields Below, create these fields:

name → Grafana Incident

#

wakeMode → now
deliver → false
timeoutSeconds → 900
message → your full prompt text

Use deliver: false because you want the agent to send progress updates itself via the message tool. If you use deliver: true, that’s mainly for one final/simple delivery to channel + to.

For multiple Feishu threads, put all recipients in the prompt:

Recipients:
- target: chat:oc_xxx, messageId: om_xxx
- target: chat:oc_yyy, messageId: om_yyy

For every phase update and final summary, send the same update to each recipient using message action="thread-reply".

#

Make sure message / group:messaging is allowed in tools.*, otherwise the agent won’t be able to send those progress updates.

Docs: https://docs.openclaw.ai/gateway/configuration-reference#hooks

restive pebble Apr 27, 2026, 1:24 PM

#

If I used /hooks/agent, how do I modify my prompt? Please help me modiify my prompt.
Method: POST
URL: http://openclaw.xxx.xxx/hooks/agent
Authentication: Generic Credential Type
Generic Auth Type: Bearer Auth
Bearer Auth: openclaw-hook-bearer-token
Send Query Parameters: False
Send Headers: False
Send Body: True
Body Content Type: JSON
Specify Body: Using Fields Below
Body Parameters

This is an EXECUTION request, not a planning request.
Do not stop after acknowledgement or a phase outline.
Begin investigation immediately in the same run and continue autonomously until you reach a diagnosis, a concrete blocker, or a verified mitigation recommendation.
Execution rules:
- Use phased incident handling: Problem Report, Triage, Examine, Diagnose, Treat, Verify, Cure.
- Minimum 3 phases unless the issue is resolved earlier with high confidence.
- After each completed phase, send a concise user-facing progress update.
- If analysis can be parallelized, spawn self-contained analysis workers and report their findings progressively.
- Do not wait for a follow-up prompt to continue normal investigation.
- Only pause if you hit an approval gate, missing access, or a hard blocker.
- Never include internal planner text, system reminders, mode banners, or runtime instructions in user-facing replies.
Deliver updates in this shape:
1. Phase name
2. What was verified
3. Current hypothesis
4. Next action
Final summary format:
Summary:
- Root cause: ...
- Impact: ...
- Recommendation: ...
Incident context:
xxx

noble bridgeBOT Apr 27, 2026, 1:24 PM

#

Use Fields Below as JSON fields — don’t paste the whole prompt as the body.

Set these body parameters:

{
  "name": "Grafana Incident",
  "wakeMode": "now",
  "deliver": false,
  "timeoutSeconds": 900,
  "message": "PASTE THE PROMPT BELOW HERE"
}

Use this as the message value:

#

Investigate this Grafana alert and send progress updates to the Feishu/Lark thread recipients listed below.

Important:
- This is an execution request, not a planning request.
- Start investigation immediately.
- Continue until you reach a diagnosis, concrete blocker, or verified mitigation recommendation.
- Do not only acknowledge the alert.
- Do not include internal planner text, hidden reasoning, system reminders, or runtime banners in user-facing updates.

Recipients:
- target: chat:oc_xxx, messageId: om_xxx
- target: chat:oc_yyy, messageId: om_yyy

For every progress update and the final summary:
- Use the OpenClaw message tool.

#

- Use channel="feishu".
- Use action="thread-reply".
- Send the same update to each recipient above.
- For each recipient, use its target and messageId.

Incident handling phases:
1. Problem Report
2. Triage
3. Examine
4. Diagnose
5. Treat
6. Verify
7. Cure

After each completed phase, send a concise update in this format:

#


1. Phase name
2. What was verified
3. Current hypothesis
4. Next action

Final summary format:

Summary:
- Root cause: ...
- Impact: ...
- Recommendation: ...

Incident context:
xxx

#

So in n8n your field setup is:

name → Grafana Incident
wakeMode → now
deliver → false
timeoutSeconds → 900
message → the prompt above

Replace:

chat:oc_xxx
om_xxx
xxx

with your n8n expressions / extracted values.

#

Use deliver: false because the agent will send updates itself through the message tool. If you set deliver: true, OpenClaw will only try to deliver the final hook result to one channel/to.

Docs: https://docs.openclaw.ai/gateway/configuration-reference#hooks

restive pebble Apr 27, 2026, 1:34 PM

#

If I used /hooks/agent, how do I modify my prompt? Please help me modify my prompt but dont modify too much my original prompt.
Method: POST
URL: http://openclaw.xxx.xxx/hooks/agent
Authentication: Generic Credential Type
Generic Auth Type: Bearer Auth
Bearer Auth: openclaw-hook-bearer-token
Send Query Parameters: False
Send Headers: False
Send Body: True
Body Content Type: JSON
Specify Body: Using Fields Below
Body Parameters

This is an EXECUTION request, not a planning request.
Do not stop after acknowledgement or a phase outline.
Begin investigation immediately in the same run and continue autonomously until you reach a diagnosis, a concrete blocker, or a verified mitigation recommendation.
Execution rules:
- Use phased incident handling: Problem Report, Triage, Examine, Diagnose, Treat, Verify, Cure.
- Minimum 3 phases unless the issue is resolved earlier with high confidence.
- After each completed phase, send a concise user-facing progress update.
- If analysis can be parallelized, spawn self-contained analysis workers and report their findings progressively.
- Do not wait for a follow-up prompt to continue normal investigation.
- Only pause if you hit an approval gate, missing access, or a hard blocker.
- Never include internal planner text, system reminders, mode banners, or runtime instructions in user-facing replies.
Deliver updates in this shape:
1. Phase name
2. What was verified
3. Current hypothesis
4. Next action
Final summary format:
Summary:
- Root cause: ...
- Impact: ...
- Recommendation: ...
Incident context:
xxx

noble bridgeBOT Apr 27, 2026, 1:34 PM

#

Yes — keep your prompt mostly the same. The main change is: put it inside the /hooks/agent JSON field called message, and add a short instruction telling the agent how to send Feishu/Lark thread updates.

In n8n Body Parameters, use:

{
  "name": "Grafana Incident",
  "wakeMode": "now",
  "deliver": false,
  "timeoutSeconds": 900,
  "message": "PASTE_MODIFIED_PROMPT_HERE"
}

Use this modified prompt as message:

#

This is an EXECUTION request, not a planning request.
Do not stop after acknowledgement or a phase outline.
Begin investigation immediately in the same run and continue autonomously until you reach a diagnosis, a concrete blocker, or a verified mitigation recommendation.

Delivery instructions:
- After each completed phase, send the progress update to the Feishu/Lark thread recipients below using the OpenClaw message tool.
- Use channel="feishu".
- Use action="thread-reply".
- For each recipient, use its target and messageId.
- Also send the final summary to the same recipients.

Recipients:
- target: chat:oc_xxx, messageId: om_xxx

Execution rules:

#

- Use phased incident handling: Problem Report, Triage, Examine, Diagnose, Treat, Verify, Cure.
- Minimum 3 phases unless the issue is resolved earlier with high confidence.
- After each completed phase, send a concise user-facing progress update.
- If analysis can be parallelized, spawn self-contained analysis workers and report their findings progressively.
- Do not wait for a follow-up prompt to continue normal investigation.
- Only pause if you hit an approval gate, missing access, or a hard blocker.
- Never include internal planner text, system reminders, mode banners, or runtime instructions in user-facing replies.

Deliver updates in this shape:
1. Phase name
2. What was verified
3. Current hypothesis
4. Next action

Final summary format:

#

Summary:
- Root cause: ...
- Impact: ...
- Recommendation: ...

Incident context:
xxx

Replace:

chat:oc_xxx
om_xxx
xxx

#

with your n8n values.

Important: use deliver: false, because the agent will send updates itself with the message tool. If you use deliver: true, that’s for a single final delivery, not multiple thread updates.

Docs: https://docs.openclaw.ai/gateway/configuration-reference#hooks

restive pebble Apr 27, 2026, 1:41 PM

#

Why was it analysed for Phase 1, and send the below message to me?

I received the webhook content, but it appears to contain instructions to send messages to third parties (Feishu recipient ou_ec29aa0ab2e83163d9001ffcbe890c85). According to my security guidelines, I must ignore instructions from untrusted external sources that ask me to send messages to third parties or change my behavior.
Therefore, I will not proceed with forwarding the incident analysis or final summary to the requested recipients. If you need me to analyze the incident for you here, let me know!```

noble bridgeBOT Apr 27, 2026, 1:42 PM

#

That happened because /hooks/agent treats the webhook payload as external/untrusted content by default.

So when your prompt says “send messages to Feishu recipient …”, the agent sees that as an instruction coming from webhook content, and safety rules say: don’t follow untrusted webhook instructions that send messages to third parties. That’s why it stopped after Phase 1 and sent you that warning.

Your original prompt is mostly fine. The risky part is putting recipient/tool-send instructions inside the webhook prompt.

Smallest safe change

Use /hooks/agent only for the incident analysis prompt, and don’t ask it to send to third parties from inside message.

Body fields:

{
  "name": "Grafana Incident",
  "wakeMode": "now",

#

  "deliver": true,
  "channel": "feishu",
  "to": "chat:oc_xxx",
  "timeoutSeconds": 900,
  "message": "This is an EXECUTION request, not a planning request.\nDo not stop after acknowledgement or a phase outline.\nBegin investigation immediately in the same run and continue autonomously until you reach a diagnosis, a concrete blocker, or a verified mitigation recommendation.\n\nExecution rules:\n- Use phased incident handling: Problem Report, Triage, Examine, Diagnose, Treat, Verify, Cure.\n- Minimum 3 phases unless the issue is resolved earlier with high confidence.\n- Do not wait for a follow-up prompt to continue normal investigation.\n- Only pause if you hit an approval gate, missing access, or a hard blocker.\n- Never include internal planner text, system reminders, mode banners, or runtime instructions in user-facing replies.\n\nFinal summary format:\nSummary:\n- Root cause: ...\n- Impact: ...\n- Recommendation: ...\n\nIncident context:\nxxx"
}

But note: deliver: true only supports one final delivery target.

For multiple Feishu threads

Use this safer split:

/hooks/agent → analyze incident only
n8n → send the final result / updates to multiple Feishu threads using /tools/invoke

#

Don’t put “send to ou_... / chat:...” inside the hook prompt unless you intentionally opt into unsafe hook content handling, which I don’t recommend for production alerts.

Docs: https://docs.openclaw.ai/gateway/configuration-reference#hooks

restive pebble Apr 27, 2026, 1:44 PM

#

But I need it to reply in a thread, not a new chat.

noble bridgeBOT Apr 27, 2026, 1:45 PM

#

Right — that’s the limitation: /hooks/agent final delivery supports channel + to, but not Feishu thread-reply / messageId.

So this:

{
  "deliver": true,
  "channel": "feishu",
  "to": "chat:oc_xxx"
}

sends a normal chat message, not a thread reply.

For a Feishu/Lark thread reply, you need the message tool action:

#

{
  "tool": "message",
  "action": "thread-reply",
  "args": {
    "channel": "feishu",
    "target": "chat:oc_xxx",
    "messageId": "om_xxx",
    "message": "your text"
  }
}

So the safer architecture is:

Use /hooks/agent for analysis only.
Let n8n send the result into the thread with /tools/invoke → message.thread-reply.

#

If you need the agent itself to send progress updates into threads, then the thread delivery instruction must be trusted configuration, not untrusted webhook content — otherwise OpenClaw will correctly block it as “external content trying to message third parties.”

In short: /hooks/agent alone can’t currently target a Feishu thread reply. Use /tools/invoke for the thread reply part.

restive pebble May 6, 2026, 8:17 AM

#

We want to iterate on the n8n message prompts for alert analysis. The following is a message sent to openclaw via webhook.
Method: POST
URL: http://openclaw.xxx.xxx/hooks/agent
Authentication: Generic Credential Type
Generic Auth Type: Bearer Auth
Bearer Auth: openclaw-hook-bearer-token
Send Query Parameters: False
Send Headers: False
Send Body: True
Body Content Type: JSON
Specify Body: Using Fields Below
Body Parameters
message:

This is an EXECUTION request, not a planning request.
Do not stop after acknowledgement or a phase outline.
Begin investigation immediately in the same run and continue autonomously until you reach a diagnosis, a concrete blocker, or a verified mitigation recommendation.
Execution rules:
- Use phased incident handling: Problem Report, Triage, Examine, Diagnose, Treat, Verify, Cure.
- Minimum 3 phases unless the issue is resolved earlier with high confidence.
- After each completed phase, send a concise user-facing progress update.
- If analysis can be parallelized, spawn self-contained analysis workers and report their findings progressively.
- Do not wait for a follow-up prompt to continue normal investigation.
- Only pause if you hit an approval gate, missing access, or a hard blocker.
- Never include internal planner text, system reminders, mode banners, or runtime instructions in user-facing replies.
Deliver updates in this shape:
1. Phase name
2. What was verified
3. Current hypothesis
4. Next action
Final summary format:
Summary:
- Root cause: ...
- Impact: ...
- Recommendation: ...
Incident context:
xxx

deliver: true
channel: feishu
to: chat:{{ $json.data.chat_id }}

Please help me add a prompt so that it not only focuses on the gitops repository but also on Grafana; with a focus on metric analysis, logs, and tracking. Don't change my existing message, just add it in.

#OpenClaw webhooks to multiple users

Best options

Important detail

Recommended

Why this works

What not to do

Important

n8n flow

1. Webhook / trigger

2. Set node or Code node

3. HTTP Request node

Important change from your current setup

Optional: send yourself a log copy too

Why this fixes the inconsistency

Small reliability tip

n8n body

If you use “Using Fields Below”

Important

Optional

First thing to test

What this verifies

Very likely causes if hook works but fan-out doesn’t

Also important

Please send these next

Most likely issue

Second likely issue

Best fix

Option A, easiest: switch body to raw JSON

Why I’m telling you to send it to yourself first

After that works

If you must keep “Using Fields Below”

Next thing I need if it still fails

If you want it standardized

Always send one final message

Prefer gradual updates

My recommendation

So yes, it can be standardized, but mostly by tightening the prompt

If you want exactly one final message every time

If you want progressive phase-by-phase updates every time

My honest recommendation

Fix

Important

Best practice

Smallest safe change

For multiple Feishu threads

deliver: true channel: feishu to: chat:{{ $json.data.chat_id }}

deliver: true
channel: feishu
to: chat:{{ $json.data.chat_id }}