OpenClaw on Synology Chat

Synology Chat is an official plugin, installed separately, that connects a NAS’s chat to OpenClaw through a webhook pair: a Synology Chat outgoing webhook posts inbound direct messages to the Gateway, and replies go back through a Synology Chat incoming webhook. Direct messages only, with text and hosted file sends. Here is the setup, the authentication and durability contract, the access policy that has no pairing flow, the three URLs that confuse people, hosted attachments, multi-account rules, and the security list.

Setup

• Install the plugin, then in the Synology Chat integrations create an incoming webhook and copy its URL, and an outgoing webhook with your secret token.
• Point the outgoing webhook at the Gateway’s webhook path, the synology path by default or a custom one, and record that exact externally reachable HTTPS URL in the config, because the NAS retrieves hosted attachments from it.
• Finish in OpenClaw through the guided onboarding or channel-add flow, or the direct command with the token, the incoming URL and the public webhook URL; then probe and message the bot.
• The token is read from the body, then the query string, then one of four accepted headers; an empty or missing token fails closed, payloads may be form-encoded or JSON, and token, user id and text are required.

Synology Chat has no pairing flow; approve senders by adding their numeric Synology user IDs to allowedUserIds.

Durability and access

After the token, sender-policy and rate-limit checks pass, OpenClaw removes the token from the stored envelope and durably queues the event before acknowledging: the route returns 204 only after the append succeeds and 503 on a persistence failure so Synology retries instead of silently losing the message, with the durable acceptance header a reverse proxy can require. Pending events survive a restart, the stable post id suppresses duplicates, and delivery is at least once across the queue-to-agent handoff. The DM policy is allowlist by default, open, or disabled: there is no pairing, senders are approved by adding numeric user ids, an empty allowlist in allowlist mode is treated as a misconfiguration and the route will not start, open requires the wildcard, and reply delivery binds to the numeric id unless a break-glass flag re-enables mutable name matching.

URLs, attachments, accounts

• Three URLs with three roles: the webhook URL is the exact public callback configured in Synology Chat, used to mint attachment capabilities; the webhook path is the internal Gateway route a proxy may map to it, exposing only that path; and the incoming URL points the other way, where OpenClaw posts replies. OpenClaw never derives the public URL from host or forwarded headers, and a missing webhook URL breaks only attachment sends.
• Outbound text is chunked at 2,000 characters with links intact. For attachments, the source is loaded under the guarded media policy, the bytes are frozen in plugin-scoped state, and the NAS receives a short-lived opaque HTTPS capability on the webhook route: ten minutes, 32 MB per file, four concurrent responses and 128 MB per minute per account, stalled responses closed after two minutes, and the original media reference never exposed.
• Multiple accounts each override token, incoming URL, public URL, path, policy and limits, with sessions isolated per account and user; every enabled account needs a distinct webhook path, duplicate exact paths are rejected, and inherited paths are refused unless a dangerous flag opts in.

OpenClaw hooks and webhooks is the durable-acceptance contract this channel shares with the others, and OpenClaw and prompt injection explains why inbound text is sanitised before the agent sees it.

Security and troubleshooting

Keep the token secret and rotate it if leaked, keep insecure SSL off unless you trust a self-signed NAS certificate, and prefer the allowlist policy in production. Inbound requests are token-verified in constant time and rate-limited per sender, thirty a minute by default, repeated invalid tokens lock the source out temporarily, and message text is sanitised against known prompt-injection patterns and truncated at 4,000 characters. Hosted attachments are served with attachment disposition, no-sniff and no-store headers, HTML, SVG and XML are rejected, and proxy logs should redact the capability token parameters. The troubleshooting list is the error messages themselves: missing required fields, an invalid token from a mismatch or a stripped header, a rate limit from repeated bad tokens, an empty allowlist, an unauthorised user, and attachments requiring the webhook URL. OpenClaw on Nextcloud Talk is the other self-hosted channel of the same shape.

On Diali

Synology Chat is not among the channels Diali connects today: the ones we run are WhatsApp, Telegram, Discord, Slack, Mattermost, Matrix, SMS and voice, and a self-run instance is where this plugin lives for now. Connect your first channel in five minutes shows our connect flow, Hosted OpenClaw on Diali is the assistant and Diali security describes the boundary.

• An outgoing webhook in, an incoming webhook out.
• No pairing: numeric ids in an allowlist, or the route does not start.
• Attachments are ten-minute capabilities, never the original URL.