OpenClaw Slack transports

Socket Mode and HTTP request URLs reach feature parity for messaging, slash commands, App Home and interactivity, so the choice is about where the gateway runs rather than what it can do. Here is the comparison the docs draw, the warning about several connections on one app, the relay mode for teams that want one ingress and many gateways, and the runtime rules of the Socket Mode connection.

The comparison

• Socket Mode needs no public gateway URL but must reach Slack's websocket host outbound, while HTTP needs a public URL with DNS, TLS and a reverse proxy or tunnel and only inbound HTTPS; Socket Mode authenticates with the bot or user token plus an app-level token carrying the connections write scope, HTTP with the bot or user token plus the signing secret that verifies every signed request.
• A dev laptop or a host behind a firewall works with Socket Mode as-is and needs a public tunnel or a staging gateway for HTTP; Socket Mode allows one session per app per host so several gateways need separate Slack apps, whereas HTTP is a stateless handler that lets several replicas share one app behind a load balancer.
• Both support several accounts on one gateway, each Socket Mode account opening its own websocket and each HTTP account needing a unique webhook path; slash commands arrive over the websocket in Socket Mode, where the command URL is ignored, and are posted to the command URL in HTTP, where the field is required for dispatch.
• On a connection drop the Slack SDK auto-reconnects and OpenClaw restarts failed Socket Mode sessions with bounded backoff under a fixed 15-second client pong timeout, while HTTP has no persistent connection and Slack retries per request; the docs pick Socket Mode for single-gateway hosts, laptops and on-prem networks with outbound access, and HTTP for replicas behind a load balancer, blocked outbound websockets or an existing webhook-terminating proxy.

Pick by deployment shape, not features.

Multiple connections and relay mode

Slack can maintain several Socket Mode connections for one app and may deliver each payload to any of them, so separate OpenClaw gateways that share one Slack app need equivalent routing and authorisation configuration; otherwise you use a separate app per gateway, a single relay ingress, or HTTP behind a load balancer. Relay mode is that single ingress: a trusted router owns the one Socket Mode connection, chooses a destination gateway and forwards a typed event over an authenticated websocket, while the gateway still uses its own bot token for outbound Web API calls. The config sets the mode to relay with the bot token and a relay block holding the router URL, an auth token and a gateway ID. The relay URL must use secure websockets unless it targets localhost, and the bearer token and the router's route table are part of the Slack authorisation boundary, because routed events enter the normal message handler as authorised activations. A router-provided Slack identity in the hello frame can set the default outbound username and icon, with an explicit caller identity still winning, and the relay reconnects with the same bounded backoff as Socket Mode and clears that identity whenever it disconnects. Relay websockets honour the gateway host's proxy environment, the upper and lowercase HTTPS, HTTP and ALL proxy variables and the no-proxy list: a secure relay uses an HTTP CONNECT tunnel when a proxy is configured, a matching no-proxy entry or a localhost plain websocket connects directly, and proxy errors are reported rather than silently falling back to a direct connection.

Socket Mode at runtime

• OpenClaw sets the Slack SDK client pong timeout to 15 seconds for Socket Mode as a fixed internal default that operators cannot change.
• The socket-mode tuning object with its client ping timeout, server ping timeout and ping-pong logging keys is retired and no longer read; the doctor flags retired tuning knobs with a general notice, its fix removes those three fields at the channel root and under each account and drops the object once empty, leaving any other key you added for you to delete by hand, and app messages and events remain application state rather than transport liveness signals.
• Restart backoff starts around two seconds and caps around thirty, recoverable start, start-wait and disconnect failures retry until the channel stops, and permanent account and credential errors such as invalid auth, revoked tokens or missing scopes fail fast instead of retrying forever.

OpenClaw on Slack is the channel post these transports carry, and OpenClaw Slack setup where each one is configured.

Why one app per gateway

The multiple-connections warning is the one that catches teams who run a staging and a production gateway on the same Slack app: Slack will happily send half the events to each, and only identical routing on both keeps that from being visible. OpenClaw remote access covers how a gateway gets a public origin for the HTTP path, and OpenClaw Slack Enterprise Grid the enterprise install where relay mode is not available at all.

On Diali

Slack is one of the channels Diali connects from the dashboard, with the runtime config generated and replaced at each release, so the transport a hosted agent uses is part of that generated setup rather than a choice you make by hand. Slack on Diali is the channel on Diali and Hosted OpenClaw on Diali the assistant behind it.

• Socket Mode needs no public URL; HTTP scales behind a load balancer.
• Two gateways on one app must route identically, or use relay.
• Backoff two to thirty seconds; bad credentials fail fast.