01_Messaging as the Control Plane
OpenClaw supports WhatsApp, Telegram, Slack, Discord, Microsoft Teams, Signal, and iMessage as first-class channels. A single deployment can serve multiple platforms at once, with shared context and memory across all channels. That makes messaging the natural control plane for remote wake and task dispatch: you send a prompt from your phone or Slack, and the agent runs on the machine where OpenClaw is installed—whether that is a local Mac or a dedicated M4 node in the cloud.
Use cases are straightforward: trigger terminal commands from a phone, assign file or data-extraction tasks, request web research with structured results, or schedule recurring workflows. The agent can reply on the same channel (e.g. WhatsApp or Slack) or into a chosen channel when invoked via the webhook API. Integration effort varies by platform: Telegram is often the fastest to get running (on the order of 30–60 minutes with a bot token), while WhatsApp and Teams typically require business or tenant setup and can take a few hours.
02_Webhook API: Remote Wake and Task Dispatch
The Gateway exposes a small HTTP webhook surface when hooks.enabled is true. Two endpoints matter for remote control: POST /hooks/wake and POST /hooks/agent. Every request must be authenticated. Query-string tokens are rejected; you must send the shared secret via Authorization: Bearer <token> or x-openclaw-token: <token>. The hook token should be distinct from gateway auth tokens and kept behind loopback, a tailnet, or a trusted reverse proxy.
POST /hooks/wake triggers a heartbeat. The payload is {"text": "description of the event", "mode": "now"}. With mode: "now" the heartbeat runs immediately; with mode: "next-heartbeat" the event is enqueued for the next periodic check. That is the primitive for remote wake: an external system (CI, calendar, email bridge) can tell OpenClaw to wake up and process pending work.
POST /hooks/agent dispatches a task to an agent. Required field is message (the prompt). Optional fields include name (human-readable hook name, e.g. "Email"), agentId (route to a specific agent; restricted by hooks.allowedAgentIds), wakeMode ("now" or "next-heartbeat"), deliver (whether to send the agent response to a messaging channel), channel (e.g. whatsapp, telegram, slack, discord, last), and to (recipient identifier: phone number, chat ID, or channel ID). You can also override model and thinking and set timeoutSeconds. The API returns 202 when the async run has been started.
Session identity is important. By default, request payloads cannot set sessionKey; the recommended pattern is to set hooks.defaultSessionKey (e.g. "hook:ingress") and keep allowRequestSessionKey: false. If you need caller-defined sessions, enable it and restrict allowedSessionKeyPrefixes (e.g. ["hook:"]) to avoid abuse. Restrict allowedAgentIds so that only intended agents can be targeted by webhook callers.
03_Channel Configuration and Recipients
Each messaging platform needs credentials and config in ~/.openclaw/openclaw.json (or the effective config path). WhatsApp typically requires Business API verification and webhook registration. Telegram needs a bot token from BotFather. Slack uses OAuth; Discord and others have their own app setup. OpenClaw documentation and community guides describe the exact steps per channel.
When you call /hooks/agent with deliver: true, you can set channel to last (use the last recipient in the main session), or explicitly to whatsapp, telegram, slack, discord, signal, imessage, or msteams. The to field identifies the recipient: phone number for WhatsApp/Signal, chat ID for Telegram, channel or user ID for Slack/Discord, conversation ID for Teams. That allows one webhook to drive tasks and send replies to the right place without going through the primary chat UI.
WhatsApp, Telegram, Slack, Discord, Teams, Signal, iMessage
Remote wake and task dispatch
Gmail, GitHub, custom mappings
04_Mappings and 50+ Service Integrations
Beyond raw /hooks/wake and /hooks/agent, the Gateway supports custom hook names via hooks.mappings. A mapping can match an incoming payload (e.g. by source or path), then run a wake or agent action with optional templates or transforms. Built-in presets like Gmail (hooks.presets: ["gmail"]) and the openclaw webhooks gmail setup flow tie into Gmail Pub/Sub so that new mail can wake the agent or post a task. Similar patterns apply to GitHub webhooks, CI systems, and internal tools.
Transforms can be JavaScript or TypeScript modules under hooks.transformsDir, allowing you to normalize third-party payloads into OpenClaw message and metadata. The docs require that the transforms directory stay under the config root (e.g. ~/.openclaw/hooks/transforms) and that traversal paths are rejected. For untrusted sources, keep the default safety wrapper; only set allowUnsafeExternalContent: true for fully trusted internal endpoints.
The "50+ services" figure reflects the combination of native channels (WhatsApp, Telegram, Slack, Discord, Teams, Signal, iMessage), webhook-driven mappings (Gmail, GitHub, custom HTTP), and the ability to plug in more via transforms and external automation. From a single OpenClaw instance you can therefore centralize triggers from email, chat, issue trackers, and cron-style schedulers, then route responses back to the appropriate channel.
05_Example: Wake and Reply to Slack
A typical flow is: an external event (e.g. a GitHub push or a cron job) calls /hooks/wake with mode: "now" so the agent runs a heartbeat and processes pending work. Alternatively, the same system can call /hooks/agent with a specific message and channel: "slack" and to set to the Slack channel or user ID. The agent runs once, and its reply is delivered to that Slack destination. No need to open the OpenClaw UI; the entire loop is messaging and webhooks.
Response codes from the Gateway are consistent: 200 for /hooks/wake, 202 for /hooks/agent (async run accepted). On failure you get 401 (bad or missing token), 400 (invalid JSON or missing required fields), 413 (payload too large), or 429 (rate limit after repeated auth failures; check Retry-After). Log these in your CI or orchestrator so you can detect misconfiguration or abuse.
For model overrides, include model in the agent payload (e.g. "model": "anthropic/claude-3-5-sonnet" or an alias). The Gateway will use that model for that run only, subject to your agents.defaults.models allowlist if you restrict allowed models. Thinking level can be set with "thinking": "low" or "high" for faster or deeper runs. timeoutSeconds caps the run duration so long tasks do not hang the worker.
06_Security and Production Hardening
Use a dedicated hook token and do not reuse gateway auth. Restrict hooks.allowedAgentIds so that webhook callers cannot target arbitrary agents; omit or use "*" only in controlled environments. Keep allowRequestSessionKey false and set defaultSessionKey unless you have a clear need for caller-chosen sessions. Restrict allowedSessionKeyPrefixes when you do allow overrides. The Gateway rate-limits repeated auth failures per client; responses include 401 on auth failure, 400 on invalid payload, 413 on oversized payloads, and 429 with Retry-After after too many failures.
Run the hook endpoint on loopback or behind a reverse proxy that terminates TLS and restricts access by IP or tailnet. Avoid logging raw hook payloads that may contain secrets. If you expose hooks to the public internet (e.g. for SaaS webhooks), use a proxy that validates signatures or tokens before forwarding.
07_Running OpenClaw on a Dedicated M4 Node
Remote control is most useful when the agent runs 24/7 on a machine that is always on and reachable. A dedicated M4 Mac in the cloud—for example a MACGPU bare-metal node—gives you a stable host for the OpenClaw Gateway and agents, with consistent IP and no sleep cycles. You then point WhatsApp Business API, Telegram, or Slack webhooks at this host (via a reverse proxy and firewall rules), and use the same webhook API from your CI or internal services.
Deploy steps: provision the node, install OpenClaw and its dependencies, configure openclaw.json with hooks.enabled: true, token, and allowed agents and session key policy. Add channel credentials for WhatsApp, Telegram, and/or Slack. Expose only the necessary ports through a reverse proxy with TLS and restrict source IPs or use a tailnet. Optionally run the Gateway under a process manager so it restarts on failure. With that in place, messages from any connected channel and webhooks from 50+ services can wake and drive the same agent, with replies delivered back to the chosen channel.
08_Summary
OpenClaw turns WhatsApp, Telegram, Slack, and other messaging platforms into remote control surfaces for your agent. POST /hooks/wake triggers a heartbeat; POST /hooks/agent dispatches a task with optional channel and recipient. Use mappings and transforms to integrate Gmail, GitHub, and custom systems, and harden with token auth, allowedAgentIds, and session key policy. For 24/7 availability, run the Gateway on a dedicated M4 node and route messaging and webhook traffic through a secure proxy. That is the core of a remote OpenClaw workflow with 50+ service integrations.