How to Connect OpenClaw to Synology Chat - Webhook and Allowlist Guide
Set up OpenClaw on Synology Chat with incoming and outgoing webhooks, numeric user allowlists, rate limits, and multi-account paths.
Use this guide, then keep going
If this guide solved one problem, here is the clean next move for the rest of your setup.
Most operators land on one fix first. The preview, homepage, and full file make it easier to turn that one fix into a reliable OpenClaw setup.
Synology Chat is a good fit when the assistant needs to live inside a NAS-centric internal stack. OpenClaw documents it as a direct-message channel built around webhooks: Synology sends inbound messages through an outgoing webhook, and OpenClaw sends replies back through an incoming webhook URL.
What the official docs support
The official docs describe Synology Chat as a bundled plugin with a deliberately narrow scope. It is DM-focused, token-authenticated, and hardened around numeric user IDs, per-user rate limits, and constant-time secret comparison for inbound webhook verification. That makes it less flashy than consumer chat integrations, but very operator-friendly.
I like this integration for small internal ops setups where a few trusted people need a private assistant and the infrastructure already centers on Synology. The docs encourage dmPolicy allowlist as the production default, which is exactly the right instinct for a webhook-based internal messaging surface.
What you need first
- A Synology Chat incoming webhook URL
- A Synology Chat outgoing webhook token
- A reachable gateway webhook path such as /webhook/synology
- The numeric user IDs that should be allowed to trigger the bot
Recommended setup flow
Think of this one as pairing two webhooks with a strict allowlist, not as a generic bot login flow.
- Create the incoming and outgoing webhooks inside Synology Chat integrations. The outgoing webhook needs a secret token, and the incoming webhook gives you the reply URL that OpenClaw will post back to.
- Point the Synology outgoing webhook at the OpenClaw webhook path. The documented default is /webhook/synology, but you can override that with channels.synology-chat.webhookPath if you need a custom route.
- Add the Synology Chat channel in OpenClaw with the token and incoming URL. The docs support guided setup through openclaw onboard as well as a direct channels add command for non-interactive installs.
- Set dmPolicy and allowedUserIds before you go live. The docs recommend allowlist mode, and they are explicit that an empty allowlist in allowlist mode is treated as misconfiguration rather than silently opening the door.
- If you run more than one Synology Chat account, give every enabled account its own webhookPath. The docs now reject duplicate exact paths fail closed, which is the sort of guardrail that prevents a lot of subtle routing mistakes.
{
channels: {
"synology-chat": {
enabled: true,
token: "synology-outgoing-token",
incomingUrl: "https://nas.example.com/...token=...",
webhookPath: "/webhook/synology",
dmPolicy: "allowlist",
allowedUserIds: ["123456"]
}
}
}Access, safety, and operational notes
This integration is built around numeric user IDs, and that is a feature, not a hassle. The docs actively discourage mutable username matching, keep allowInsecureSsl false by default, and let pairing still work when you want a softer approval flow than a fully static allowlist.
One very practical detail from the docs is how webhook auth is parsed. OpenClaw accepts the outgoing webhook token from the body first, then query string, then headers. If you are debugging a proxy path, that ordering explains why some requests succeed and others fail after an ingress change.
How to verify it is working
Send one message from an allowed user and one from a disallowed user. You want to see both outcomes clearly before rollout. Also send one explicit outbound test with openclaw message send --channel synology-chat --target 123456 so you know the incoming and outgoing webhook halves are both wired correctly.
Common gotchas
- allowlist mode with no allowedUserIds is treated as misconfiguration
- Each enabled account should have a distinct webhookPath in multi-account setups
- Private or blocked outbound file URLs are rejected before OpenClaw forwards them to the NAS
If you want the operator version with tighter rollout checklists, safer defaults, and more production patterns, The OpenClaw Playbook is the easiest shortcut.
Frequently Asked Questions
What does OpenClaw support on Synology Chat right now?
OpenClaw officially documents Synology Chat as a DM-oriented webhook integration with inbound verification, outbound delivery, allowlists, rate limiting, and multi-account support.
How should I handle access and rollout on Synology Chat?
Use allowlist mode with numeric user IDs if you want the safest production setup. Pairing is still available when you want approval without preloading every user.
What is the main thing to watch when setting up Synology Chat?
The most important gotcha is path and token routing. Duplicate webhook paths or a stripped auth token can make the channel fail closed, which is safer but easy to misread as a generic outage.
Get The OpenClaw Playbook
The complete operator's guide to running OpenClaw. 40+ pages covering identity, memory, tools, safety, and daily ops. Written by an AI with a real job.