2026 OpenClaw MeshMac: Microsoft Teams Incoming Webhook for Multi-Node Build Status

OpenClaw 2026 Gateway Primer on MeshMac

Start from the same posture as our multi-node deployment guide: pick one logical gateway (dedicated small VM, bastion, or a designated Mac) that runs OpenClaw services, owns outbound integrations, and reads secrets from disk or a sealed volume. On each builder, set OPENCLAW_CONFIG_ROOT if you split config trees per project as in per-project config and logs, but do not copy the Teams webhook URL onto every node—workers should enqueue “build finished” records and let the gateway POST to Microsoft.

After install, run your normal openclaw onboarding and health checks (doctor, log tail) so you know the process starts under LaunchDaemon with the expected environment. Wire internal delivery through the shared queue pattern described in multi-node deploy and task queue sync so CI handoffs between Macs do not fork notification code paths. For a chat-platform comparison, see Matrix webhook build status—the architecture is parallel; only the HTTPS target and JSON schema change.

More OpenClaw articles are listed on the OpenClaw hub. General webhook hardening (signing, replay windows) overlaps with shared build notify webhooks; apply the same discipline even though Teams Incoming Webhooks are URL-bearer style rather than HMAC-first.

Teams Connector and URL Security

In the target Microsoft Teams channel, add an Incoming Webhook connector (or the successor workflow your tenant exposes), generate the URL once, and treat the entire string as a bearer credential: anyone who can POST to it can spam the channel. Store it in /etc/openclaw/secrets.d/teams/build-status.url or your equivalent with mode 0440, owner root, group a dedicated openclaw-notify role, matching the layout in secrets and least privilege on MeshMac nodes.

• Never log the full URL. Print host plus last four characters of the path token when debugging.
• Rotate by replacement. Delete the connector, create a new webhook, swap the file, reload the gateway—document this in IM alerts and token rotation.
• Separate environments. Staging and production channels get different URLs so a mis-tuned workflow cannot announce fake green builds to executives.
• Payload hygiene. Use Microsoft-supported JSON (for example MessageCard @type, summary, title, text sections). Malformed bodies return 400 and are easy to mistake for “Teams is down.”

If your organization restricts classic connectors, plan B is Power Automate or an Azure Logic App that exposes a narrowly scoped HTTPS endpoint you call from the gateway—the security model is the same: one secret, one sender, audited rotation.

Gateway and Proxy Outbound Allowlists

MeshMac builders often sit behind a corporate forward proxy or egress firewall. The gateway host must perform HTTPS POST to Microsoft’s webhook endpoints. Work with security to allow TLS to the hostnames your tenant actually hits—commonly under outlook.office.com and *.webhook.office.com—and to pin the proxy if you intercept TLS. Deny direct internet from self-hosted CI runners except through that gateway hop.

Operational checklist: from the gateway shell, curl -I the webhook host through the same proxy variables the daemon uses; if CONNECT fails, OpenClaw will never reach Teams even when local unit tests pass. Mirror the split between “CI talks to gateway” and “gateway talks to SaaS” that we use for other integrations, so you only maintain one outbound policy for Microsoft.

When multiple nodes previously called the webhook directly, consolidate and remove their egress exceptions—this shrinks attack surface and makes failover drills simpler because only the gateway IP needs allowlist updates.

Multi-Node Status Aggregation Field Design

Every provider emits different JSON. Normalize on the gateway before rendering Teams text or cards:

Optional: include duration_sec and queued_sec when your queue metrics come from the same OpenClaw task fabric as task queue retry steps—executives notice slow pools faster than raw log URLs.

Retry and Idempotency

Microsoft may return 429 under throttle or transient 5xx from the edge. Use exponential backoff with jitter, cap total attempts (for example five over two minutes), and record the last HTTP status in gateway logs—not in CI stdout. Align timeouts with the guidance in task queue retry steps: separate “retry network” from “retry the build.”

Idempotency: key on provider_run_id + state (or equivalent) and skip emitting a second Teams message when the same transition was successfully acknowledged within 72 hours. Store keys in SQLite, Redis, or even a small file if traffic is low. Without this, fast retries after a slow response will duplicate cards and train the team to mute the channel.

Do not retry blindly on 400 or 401; fix the JSON or rotated URL first. Treat 404 on the webhook as “connector deleted” and page whoever owns Teams governance.

FAQ: No Message in Teams

CI step is green but the channel is empty

Verify the gateway process actually executed the POST (structured log line with status code). Test with curl from the gateway using a minimal JSON body. Confirm the connector still exists—admins sometimes disable legacy connectors tenant-wide.

Intermittent failures only from certain nodes

Those nodes are probably still calling Teams directly with an old secret or bypassing the proxy. Enforce the single-gateway path and remove per-node egress rules.

HTTP 200 but blank or error card

Teams accepted the request yet rejected the payload at render time. Validate @type, required summary/title fields, and length limits; shrink attachments when mobile clients truncate.

Everything worked until Monday morning

Check weekend certificate rotation on the forward proxy, DNS drift for Microsoft endpoints, and secret rotation jobs that touched the wrong file. Compare against token rotation runbooks.