OpenClaw on Google Chat

Google Chat is one of the channels OpenClaw serves through webhooks: the official plugin handles DMs and spaces through the Chat API, over an HTTP endpoint only, with no Pub/Sub subscription. That shapes the whole setup: a Google Cloud project, a service account, a Chat app pointed at a public URL, and a decision about how to expose that one path without exposing the Gateway. Here are the setup steps in the docs’ order, how the app is found once it is live, and the exposure recipe.

The setup

• Create a Cloud project and enable the Chat API; create a service account with no permissions; create and download its JSON key and store the file on the Gateway host.
• Create a Chat app in the console: application info, interactive features on, joining spaces and group conversations allowed, an HTTP endpoint URL as the connection, one common endpoint for all triggers set to the public Gateway URL followed by the channel path, and visibility limited to specific people in your domain.
• Set the app status to live, then configure OpenClaw with the service account file, through an environment variable for the default account or config, and the webhook audience that has to match the app; the channel wizard accepts the audience and webhook flags.
• Start the Gateway; Google Chat posts to the webhook path, and the app is added from the plus button next to direct messages by searching its name, because a private app never appears in the Marketplace list.

Google Chat webhooks require a public HTTPS endpoint.

Exposing one path

The docs are specific: expose only the channel path to the internet and keep the dashboard and every other endpoint private. The recommended way is Tailscale in two roles, Serve for the dashboard on a tailnet-only port and Funnel for the single webhook path, after checking which address the Gateway is bound to, loopback, all interfaces or a tailnet address, because the Serve target depends on it.

What to keep in mind

• Visibility is the access control at Google’s end: the app is available only to the people and groups you list, and pairing is the access control at OpenClaw’s end.
• The audience in the config must match the Chat app configuration, or webhook validation fails silently from the outside.
• The service account key is a credential like any other: store it outside the workspace and reference it, never paste it into chat.

OpenClaw and Tailscale explains Serve and Funnel, and OpenClaw pairing the approval step that follows the first message.

On Diali

On Diali, Google Chat is on the roadmap rather than in the connect list; the Cloud project and the Chat app would still be yours, and the public webhook path would be ours to expose. Hosted OpenClaw on Diali is the assistant, and Slack on Diali is the workplace channel that connects today.

• A service account, a Chat app, a webhook path, no Pub/Sub.
• Expose one path with Funnel; keep the dashboard on Serve.
• Visibility gates Google’s side; pairing gates OpenClaw’s.