How to Use OpenClaw with Slack

Slack is a strong OpenClaw home when you want quick approvals, thread-aware updates, and a place where humans already expect compact operational messages. The docs are mature here, and the nicest part is that they give you a clean default: Socket Mode first, HTTP mode only when you actually need request URLs.

Start with one clean path

Start with one Slack app, one workspace, and one mode. In Socket Mode, you create the Slack app from a manifest, generate an app-level token with connections:write, install the app, grab the bot token, and point OpenClaw at those credentials. That route avoids public request URLs and is the shortest path to a working setup. If you later need HTTP mode, the docs cover signing secrets and unique webhook paths for multi-account setups.

That restraint matters. The fastest way to make a channel integration feel noisy is to turn on every surface at once. OpenClaw gets better when you bring one route online, verify the auth model, check the session behavior, and only then expand into alerts, commands, or additional accounts.

Base configuration

The scope checklist is detailed for a reason. Slack integrations fail less from missing code than from missing permissions. Follow the manifest closely, especially the bot scopes for reading channel history, writing chat messages, commands, reactions, files, and pins. Once the tokens are in place, the gateway command itself is almost boring. That is a good sign. Most of the real work is in app creation and scopes, not in some magical OpenClaw incantation.

{
  channels: {
    slack: {
      enabled: true,
      mode: "socket",
      appToken: "xapp-...",
      botToken: "xoxb-...",
    },
  },
}

SLACK_APP_TOKEN=xapp-...
SLACK_BOT_TOKEN=xoxb-...

openclaw gateway

• Use Socket Mode by default unless you specifically need HTTP request URLs.
• Create the Slack app from the documented manifest so scopes and events are correct from day one.
• Keep Slack thread behavior explicit in your workspace rules so updates land where the work lives.
• Remember that Slack DMs default to pairing mode, so inbound access is still gated.

Operational habits that keep it sane

Once Slack is live, the real operator move is restraint. Start with one or two channels where OpenClaw clearly helps, usually an ops lane and maybe a private approval lane. Confirm that thread replies stay in-thread, that the pairing model matches your expectations, and that the bot is not waking up in casual chatter. After that, Slack becomes a very comfortable control surface for human review and small decisions.

The main failures are permission drift and overexpansion. If a scope is missing, the integration will feel flaky in ways that waste time. If you connect OpenClaw to too many noisy channels before you set social rules, Slack will feel like the bot problem, when really it is a routing problem. The docs give you enough to avoid both, but only if you treat app setup and channel design as part of the same job.

A clean Slack setup makes OpenClaw feel like a teammate in the room instead of a webhook with opinions. If you want the practical operator layer on top of the official docs, The OpenClaw Playbook turns setups like this into real workflows, guardrails, and day-to-day patterns you can actually run.

If you later move to HTTP mode, keep the docs' warning in mind about unique webhook paths for multi-account setups. Colliding request URLs are the kind of low-drama configuration bug that can quietly burn a whole afternoon.

The optional extras are useful when you know why you need them. chat:write.customize lets outgoing messages use the active agent identity, and a config-only userToken can expand read behavior when you need deeper Slack reads. Both are nice upgrades, but neither should be step one.

The docs also note that native slash commands are available, with a practical limit of twenty-five commands. That is plenty, but it is another reason to choose a small, intentional command set instead of turning your Slack app into a cluttered toolbar.