Anyone have success with setting up Synology Chat? | Friends of the Crustacean 🦞🤝 | Page 1

sly harbor Mar 8, 2026, 2:18 PM

#

I have been working with my OpenClaw almost 2 days now trying to get Synology Chat functioning. I can receive a message from my OpenClaw but for some reason it cannot receive one. I setup integration with Webhooks etc. Does someone have a link, walkthrough or some direction they can give me?

ashen jewelBOT Mar 8, 2026, 2:18 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

fringe dustBOT Mar 8, 2026, 2:22 PM

#

Synology Chat inbound only works if the Synology Chat plugin is installed + your NAS can reach your Gateway’s outgoing-webhook URL. The doc + minimal config are here: https://docs.openclaw.ai/channels/synology-chat

For your specific symptom (“OpenClaw can send to Chat, but Chat → OpenClaw never arrives”), it’s almost always one of these:

1) The outgoing webhook isn’t hitting your Gateway (network/URL)

In Synology Chat you need an outgoing integration pointing to your gateway, e.g.:

https://<your-gateway-host>/webhook/synology (default path)
or whatever you set as channels.synology-chat.webhookPath

If the Gateway is only on LAN/VPN and the NAS can’t reach it, OpenClaw will never see inbound messages.

Debug: tail logs, then send a DM in Synology Chat:

openclaw logs --follow

If you see nothing at all when you send a message, it’s URL/routing/firewall/DNS.

#

2) Token mismatch (401)

The config channels.synology-chat.token must match the outgoing webhook “secret token” you set in Synology Chat (people often accidentally use the incoming webhook URL token instead).

In logs you’ll see: Invalid token ... and Synology will get a 401.

3) DM allowlist blocking you (403)

If you have:

dmPolicy: "allowlist",
allowedUserIds: [...]

…then the Synology user_id must be in allowedUserIds, otherwise inbound gets rejected.

Fast way to confirm: temporarily set dmPolicy: "open" (allow all), restart, test inbound, then switch back to allowlist once you’ve confirmed your numeric user_id.

Quick sanity checks to paste back (with secrets redacted)

openclaw --version

#

openclaw plugins list (make sure synology-chat is installed + enabled)
Your channels.synology-chat config block (redact tokens/URLs), especially: token, webhookPath, dmPolicy, allowedUserIds

If you paste the first ~20 lines around the Synology Chat log entries from openclaw logs --follow, we can tell immediately which of the 3 buckets you’re in.

sly harbor Mar 8, 2026, 2:44 PM

#

1:
openclaw --version
2026.3.2

2:
│ Synology │ synology │ loaded │ stock:synology-chat/index. │ 2026.3.2 │
│ Chat │ -chat │ │ ts │ │

3:
{
"channels": {
"synology-chat": {
"enabled": true,
"token": "[REDACTED]",
"incomingUrl": "https://192.168.1.1:5001/webapi/entry.cgi?api=SYNO.Chat.External&method=chatbot&version=2&token=[REDACTED]",
"webhookPath": "/webhook/synology",
"dmPolicy": "[REDACTED]",
"allowedUserIds": "[REDACTED]",
"allowInsecureSsl": true,
"rateLimitPerMinute": 30,
"allowFrom": "[REDACTED]"
}
}
}

fringe dustBOT Mar 8, 2026, 2:45 PM

#

Nice, thanks — version + plugin load looks good.

A couple things jump out from that config + the “can send to Synology but can’t receive” symptom:

1) `allowFrom` isn’t a Synology Chat setting (and won’t help inbound)

For Synology Chat, inbound auth is controlled by:

dmPolicy
allowedUserIds

So if you put your ID(s) into allowFrom (and allowedUserIds is empty/wrong), the webhook route will either:

not start at all (if dmPolicy: "allowlist" + allowedUserIds empty), or
start but 403 you (“User not authorized”).

Suggestion: remove allowFrom to avoid confusion, and make sure allowedUserIds is set.

Docs: https://docs.openclaw.ai/channels/synology-chat

#

2) Double-check you’re using the outgoing webhook token in `token`

channels.synology-chat.token must match the Synology Chat outgoing webhook “secret token” (not the token=... that’s embedded in your incomingUrl).

If this is wrong you’ll see 401 Invalid token in gateway logs.

3) The fastest way to pinpoint it: check gateway logs while you DM the bot

Run:

openclaw logs --follow

Then send a DM to the Synology Chat bot/integration.

You’re looking for one of these in logs:

Registered HTTP route: /webhook/synology for Synology Chat (good; route exists)
Invalid token (token mismatch)
Synology Chat allowlist is empty... (allowedUserIds empty)

#

Unauthorized user: <id> (your allowedUserIds doesn’t include the webhook’s user_id)

If you paste the ~10–30 log lines that appear when you send the DM, we can tell exactly which branch you’re hitting.

4) Quick “get it working” test

Temporarily set:

dmPolicy: "open"

Restart gateway, DM again, confirm inbound works, then switch back to allowlist once you’ve captured the correct user_id from logs and put it into allowedUserIds.

If you reply with your openclaw logs --follow snippet from a failed inbound attempt, I’ll point to the exact fix.

sly harbor Mar 8, 2026, 3:39 PM

#

In Synology in Login Portal do you need to setup Synology Chat Web Services, and under Security->Certificate do you need to Import a certificate from OpenClaw?

sly harbor Mar 9, 2026, 3:16 AM

#

After hours of trying to get this working with OpenClaws help we have verified that it is the Synology DSM (I am running V 7.3.2-86009) rejecting the cert. Here is it's last output:

"This is actually great news — the network and firewall are completely fine. Synology Chat IS reaching OpenClaw on port 443. The TCP handshake completes successfully (SYN → SYN-ACK → ACK), data is exchanged, then the connection closes. That's the TLS handshake failing after our cert is presented.

This is 100% confirmed as SSL cert trust — nothing else. The packet arrives, nginx answers, DSM rejects the cert.

There's no routing issue. The only fix is getting DSM to trust our cert. Let me guide you through it precisely:

Open DSM → Control Panel → Security → Certificate
Click Add
Select "Add a new certificate" (or similar)
Look for an option like "Import certificate" or on some DSM versions there's a separate tab/button for "Trusted Root Certificate"

What do you see when you click Add? I need the exact option names so I can direct you to the right one."

fringe dustBOT Mar 9, 2026, 3:18 AM

#

Yep — that diagnosis tracks. Synology Chat’s outgoing webhook client does strict TLS verification, and on the OpenClaw side there’s no “allow insecure inbound TLS” knob (your allowInsecureSsl: true only affects OpenClaw → Synology, not the other direction).

So the fix is on the URL/cert that DSM is connecting to. In practice you’ve got 3 workable options:

Option A (simplest on LAN): use plain HTTP for the outgoing webhook

If your NAS and Gateway are on the same network/VPN, change the Synology outgoing webhook URL to:

http://<gateway-host>/webhook/synology (no TLS)

This avoids DSM’s cert trust store entirely. (You may need nginx to listen on port 80 and proxy to the gateway.)

Option B (best long-term): put a publicly-trusted cert on your OpenClaw webhook endpoint

Use a normal CA cert (Let’s Encrypt is easiest) on the nginx that fronts OpenClaw, then point Synology Chat to:

https://your-real-hostname.example.com/webhook/synology

Two common gotchas that look exactly like “DSM rejects the cert”:

Hostname mismatch: if Synology is calling https://192.168.x.y/... but your cert is for mydomain.com, it will fail even if the CA is trusted. Use the hostname that matches the cert’s SAN/CN.

#

Missing intermediate chain: nginx must serve the full chain (e.g. Let’s Encrypt fullchain.pem, not just cert.pem). Some clients are less forgiving than browsers.

Option C (advanced / not my fave): import your private CA into DSM’s system trust store

DSM’s Control Panel → Security → Certificate UI is mainly for certs DSM presents to others; it often does not affect what DSM trusts for outbound HTTPS (like Synology Chat webhooks). Usually this ends up being an SSH-level “add CA cert to system bundle” task, and updates can overwrite it.

Quick question so I can point you at the right exact fix

In Synology Chat’s outgoing webhook URL, are you using an IP address (https://192.168...) or a hostname (https://something.yourdomain)?

If it’s an IP, Option A (HTTP) or switching to a hostname that matches your cert is usually the fastest win. If it’s already a hostname + LE cert, then we should check the fullchain/intermediate issue next.

sly harbor Mar 9, 2026, 3:20 AM

#

The outgoing webhook URL is an ip address https://192.168...

fringe dustBOT Mar 9, 2026, 3:20 AM

#

That’s the root of it.

With https://192.168.x.y/... you’ll almost always lose, because:

the cert can’t match 192.168… (unless you mint a cert with an IP SAN), and
public CAs (Let’s Encrypt, etc.) won’t issue certs for private RFC1918 IPs anyway.

So you basically have two sane paths:

Path 1 (recommended for LAN): switch the Synology outgoing webhook URL to HTTP

Change it to:

http://192.168.x.y/webhook/synology

Then make sure whatever is fronting OpenClaw actually listens on port 80 (nginx) or point it directly at the gateway’s HTTP port if you’re not using nginx for that.

After that, openclaw logs --follow + send a DM in Synology Chat should immediately show the inbound webhook.

#Anyone have success with setting up Synology Chat?