2026 OpenClaw Slack / Discord Webhooks : démon Mac cloud reproductible

Après le premier déploiement en cinq étapes, les équipes veulent Slack ou Discord—et bloquent sur Webhook vs Bot, veille du portable et doublons. Ce guide 2026 donne un tableau de décision, cinq étapes ou plus (env, curl, launchd), croisé avec durcissement production et dépannage ; la sortie IM est une infra au même niveau que le port 18789.

1. Three pain classes: auth model, process lifetime, message storms

IM integration is more than pasting a URL. First, wrong auth depth: Slack Incoming Webhooks post to one channel only; Bot apps need correct OAuth scopes or you get 403 loops. Second, lifetime tied to a GUI session: npm start on a laptop dies on sleep or Wi‑Fi blips—teams blame “OpenClaw” when the host is wrong. Third, storms without throttling: each tool call posting to IM can flood a channel in seconds; without batching, ops disables the integration.

Never commit Webhook URLs: treat them like bearer tokens; inject via SSH secrets, env files mode 600, or orchestrator secrets.
Align egress with gateway policy: the gateway often binds 127.0.0.1:18789 per the firewall checklist; IM calls use 443—allow Slack/Discord hostnames explicitly if you run tight outbound rules.
Keep logs consistent across Docker/npm/source: switching install styles per the comparison article without syncing env paths yields “works locally, silent in cloud”.

Use the next table in design reviews so you do not over-build a Bot when a Webhook suffices.

2. Webhook vs Slack App vs Discord Bot

Slack encourages granular bot tokens and event APIs; Discord webhooks are ideal for one-way alerts, while Bots add Gateway complexity. For OpenClaw, nightly summaries and build/agent alerts usually stop at Webhook; conversational @agent flows need Bot capabilities.

Option	Capabilities	Complexity	Secret shape	Typical OpenClaw use
Slack Incoming Webhook	Post to a fixed channel	Low	Long HTTPS URL	Alerts, summaries, job done
Slack App + Bot	Events, buttons, threads	Medium–high	Bot token + signing secret	Interactive ops bots
Discord Webhook	One-way embeds	Low	Webhook URL	Community/dev channel feeds
Discord Bot	Messages, commands, Gateway	High	Bot token	Conversational triggers

If you already run production hardening, rotate IM credentials independently from gateway tokens so one leak does not compromise both planes.

3. Reproducible steps: Slack, Discord, launchd, validation

Assume OpenClaw already runs under a non-interactive macOS user on cloud Mac with SSH. Keep order for easy rollback.

Create least-privilege integrations: Slack Incoming Webhook or Discord channel webhook; record owner and rotation date in your secret manager.
Add a restricted env file on the node: e.g. /usr/local/etc/openclaw/im.env chmod 600 with SLACK_WEBHOOK_URL or DISCORD_WEBHOOK_URL only.
Reference variables from OpenClaw config: never hard-code URLs in git; for Docker use --env-file or orchestrator secrets.
curl smoke test: POST minimal JSON from the server before wiring agent logic—verify HTTP status and channel delivery.
launchd plist or equivalent supervisor: RunAtLoad, KeepAlive, ThrottleInterval; redirect stdout/stderr to a rotated log such as /var/log/openclaw/im-bridge.log.
Rate limit and summarize: merge same-topic events within 30s or gate on ERROR level to avoid spam.

# Slack Incoming Webhook smoke test (never commit real URLs)
curl -X POST -H 'Content-type: application/json' \
  --data '{"text":"OpenClaw: smoke test from mac-cloud node"}' \
  "$SLACK_WEBHOOK_URL"

# Discord Webhook smoke test
curl -X POST -H 'Content-type: application/json' \
  --data '{"content":"OpenClaw: smoke test from mac-cloud node"}' \
  "$DISCORD_WEBHOOK_URL"

                Tip: User-level vs system-level launchd differs; mixing CI SSH users with GUI logins causes “variables present in SSH but missing after reboot”.

4. Parameters you can cite

For runbooks: ① Slack webhooks expect HTTPS POST JSON, often text or Block Kit payloads—log HTTP status bodies on failure. ② Discord returns 429 on abuse; backoff exponentially. ③ If the gateway stays on loopback, future inbound IM callbacks need a reverse proxy or tunnel consistent with your 18789 exposure policy. ④ Export IM send success/fail counters or structured logs to align with triage playbooks.

5. Why IM bridges belong on dedicated Mac cloud nodes

Running bridges only on a shared laptop gives sleep gaps, weak audit trails when multiple people share a session, and correlated failure if the gateway OOMs on the same box. Hosting the notifier on SSH-managed Mac cloud with explicit restart policy separates “chat delivery” from “agent compute” degradation.

Renting VPSMAC M4 Mac cloud capacity for OpenClaw plus IM egress is usually more predictable than tethering to personal hardware: power and network are platform-owned, launchd and log rotation match Linux-style ops, and you keep the Apple toolchain. Baseline install: five-minute OpenClaw deployment, then apply this article for Slack/Discord.

6. FAQ

Duplicate Slack messages—where to look?

Check duplicate event handlers or retries that ignore 2xx; verify only one webhook targets the channel.

Bot only, no Webhook?

Yes, but higher cost; use Webhook for one-way feeds, Bot when you need interaction.

How does this relate to WeCom?

Enterprise WeChat uses a different API and compliance path; see our WeCom article—this piece targets Slack/Discord HTTPS webhooks.