2026 OpenClaw MeshMac: Google Chat Space Webhook for Multi-Node Build Status

Gateway installation and token

Mirror the gateway-first topology from our multi-node deployment guide: one host (bastion, small Linux VM, or a designated Mac) runs OpenClaw services, owns outbound webhooks, and reads secrets from a sealed directory. Builder nodes enqueue events; they must not each hold a copy of the Chat URL.

After install, set OPENCLAW_CONFIG_ROOT, complete onboarding, and run health checks so the daemon starts with the same environment your CI will rely on. Place the webhook target in something like /etc/openclaw/secrets.d/google-chat/build-status.url with mode 0440, owner root, and group a dedicated openclaw-notify role.

Checkpoint A — file permissions.

sudo install -d -m 0750 -o root -g openclaw-notify /etc/openclaw/secrets.d/google-chat
sudo sh -c 'umask 077; cat > /etc/openclaw/secrets.d/google-chat/build-status.url' <<'EOF'
https://chat.googleapis.com/v1/spaces/SPACE/messages?key=KEY&token=TOKEN
EOF
sudo chown root:openclaw-notify /etc/openclaw/secrets.d/google-chat/build-status.url
sudo chmod 0440 /etc/openclaw/secrets.d/google-chat/build-status.url

Replace the placeholder URL with the value Google Chat shows when you create the webhook. Internal delivery from many Macs should follow the shared queue pattern in multi-node deploy and task queue sync so notification code never forks per runner.

Multi-platform note: Microsoft Teams incoming webhooks use Office 365 hosts and card JSON; Matrix uses room access tokens or appservice webhooks. Your gateway field map stays identical; only the renderer and HTTPS target differ—mirror the same checklist for each provider.

Google Chat incoming webhook configuration

In the target Google Chat space, add the Incoming Webhook integration (name it after your repo or pool), choose the space, and copy the generated URL once. The URL embeds key and token query parameters—functionally a bearer credential. If it leaks, revoke and recreate the webhook; there is no partial rotation.

• Separate spaces per environment so a staging workflow cannot post “green” into an executive production space.
• Egress: from the gateway shell, confirm TLS to chat.googleapis.com works through the same HTTPS_PROXY variables the daemon uses.
• Admin policy: if Workspace blocks custom webhooks, use an approved Chat app or HTTP endpoint from Apps Script—still keep a single gateway sender.

Checkpoint B — reachability.

export HTTPS_PROXY="${HTTPS_PROXY:-}"
curl -sS -o /dev/null -w "%{http_code}\n" -I "https://chat.googleapis.com/"

You expect a Google-controlled response (often 404 on bare GET) but not TLS handshake failures or proxy 403 blocks. Fix network policy before debugging application JSON.

Message payload template

The smallest reliable body for app-generated text is UTF-8 JSON with a text field. Cards and interactive widgets are optional once plain text proves delivery.

export CHAT_URL="$(sudo cat /etc/openclaw/secrets.d/google-chat/build-status.url)"
curl -sS -X POST "$CHAT_URL" \
  -H 'Content-Type: application/json; charset=UTF-8' \
  -d '{"text":"MeshMac gateway probe: OK from '"$(hostname -s)"'"}'

Checkpoint C — message visible. You should see the probe line in the Chat space within seconds. If the API returns JSON with an error object, pretty-print it and fix the body before enabling automation.

For production notifications, render one line with emoji or labels for state, then append mesh_node_id and a short commit hash. Keep under Chat length limits; link to the provider run URL instead of pasting logs.

For Microsoft Teams, swap in connector card JSON and allowlist *.webhook.office.com instead of Google hosts; the gateway queue and field table stay the same.

Multi-node status aggregation example

Assume three MeshMac builders finish jobs within the same minute. Each runner publishes a normalized record to Redis, NATS, or the OpenClaw task fabric. The gateway consumer maps provider payloads into this internal shape before formatting text:

Example rendered text (single POST):

✅ ios-release · main · abc1234 · <https://github.com/org/repo/actions/runs/18451203> · node mm-pool-2

If two nodes report the same provider_run_id and state, the gateway should dedupe within your chosen window (often 24–72 hours) so flaky retries do not spam the space. Align retry mechanics with task queue retry steps for the internal queue, separate from “re-run the build.”

Authentication and retry FAQ

Is the webhook URL an OAuth token?

No. It is an unscoped HTTPS endpoint secret. Protect it like an API key: filesystem ACLs, no Git, redacted logs (host plus last four characters of the token parameter only).

Which HTTP codes should trigger retry?

Retry 429 and 5xx with exponential backoff, jitter, and a small cap (for example five attempts over two minutes). Do not retry 400 or 401; fix JSON or rotate the webhook. Treat repeated 404 as “webhook deleted.”

How do I avoid duplicate Chat messages?

Store successful deliveries under provider_run_id + state in SQLite, Redis, or a gateway-local cache. Skip a second POST when the key exists inside the dedupe window.

Can builders call Chat directly “just for now”?

That multiplies secrets and egress rules. Consolidate on one gateway process so rotation, auditing, and failover drills stay predictable.