How to Use OpenClaw with Google Chat

OpenClaw's Google Chat channel connects a gateway to Google Chat DMs and spaces through HTTP webhooks. The setup is more involved than a simple token because Google Chat apps live in Google Cloud, use a service account, and require a public HTTPS endpoint for inbound events. The key operator principle is separation: expose the /googlechat webhook path, but keep the dashboard and other admin surfaces private.

Create the Google side first

The docs start in Google Cloud. Create or choose a project, enable the Google Chat API, create a service account, and download a JSON key to the gateway host, for example ~/.openclaw/googlechat-service-account.json. Then create a Google Chat app in the Chat API configuration screen. Enable interactive features, choose an HTTP endpoint, select the relevant functionality for spaces and group conversations, and set visibility so the intended users can find the private app.

Configure endpoint and credentials

The common endpoint is your gateway's public URL followed by /googlechat. The credential path can be set with GOOGLE_CHAT_SERVICE_ACCOUNT_FILE or channels.googlechat.serviceAccountFile. You also need the webhook audience type and value to match the Chat app configuration. After the gateway is running and the app status is live, users can find the app in Google Chat by its app name, add it, and send a first message.

Expose only the webhook

The docs are explicit: Google Chat webhooks require public HTTPS, but only the webhook path should be public. A recommended path uses Tailscale Serve for private dashboard access and Tailscale Funnel for the public /googlechat path. That gives Google a reachable endpoint while keeping / private on your tailnet. Do not solve webhook reachability by opening the entire gateway root to the internet; that turns a channel integration into a control-plane exposure.

Test private app discovery

Because the app is private, users may not see it in a marketplace browse list. The docs say to search for the app name from Google Chat's Direct Messages add flow. If the bot does not appear, check visibility settings, app status, and whether the user's email or group is allowed. If messages do not arrive, verify the endpoint URL, HTTPS reachability, service account file path, and gateway logs for webhook requests.

Operational checklist

Keep the service account JSON on the gateway host with tight filesystem permissions, write down the Chat app name, endpoint path, audience value, and visibility list, and test one DM plus one space before inviting a team. The OpenClaw Playbook's channel setup pattern is simple: one credential source, one public path, one private dashboard path, and one rollback note. Google Chat rewards that discipline because it spans Cloud Console, gateway config, and user-facing chat UX.

Separate Google Cloud setup from chat UX

Most Google Chat failures come from mixing Cloud Console concepts with chat-user expectations. The service account, Chat API, app status, HTTP endpoint, and visibility list are administrator concerns. Finding the app, adding it to a DM, and sending the first message are user concerns. Document both paths separately. If a user cannot see the app, do not start by changing gateway credentials; check visibility and app status. If Google cannot deliver events, do not ask the user to reinstall the bot; check endpoint reachability and logs. Clear ownership makes the integration much easier to operate.

Final verification

Before calling How to Use OpenClaw with Google Chat finished, perform one direct test, one failure test, and one rollback check. The direct test proves the happy path works. The failure test proves the documented guardrail is real, not just assumed. The rollback check tells the next operator how to undo the change without improvising. Save those notes beside the channel, node, or gateway config you changed. OpenClaw gets powerful when agents can act, but it stays trustworthy when every new surface has a small, repeatable verification habit attached to it.