Connecting OpenClaw AI Agents to Google Chat - Setup and Configuration

Not every organisation runs Slack. Plenty of Australian businesses - particularly those already invested in Google Workspace - have their teams in Google Chat. And when you want to deploy an AI agent where people actually work, you go where the conversations are.

OpenClaw's Google Chat channel is production-ready for both direct messages and spaces (group conversations). It uses the Google Chat API with HTTP webhooks, which means your OpenClaw gateway needs a public HTTPS endpoint. That's a bit more setup than Slack's Socket Mode, but it's straightforward once you understand the pieces.

I've set this up for a few clients now, and the process is reliable if you follow the steps in order. Let me walk through it practically.

What You Need Before Starting

You'll need a Google Cloud project with billing enabled, a service account (for OpenClaw to send messages back), and a public HTTPS URL that Google can send webhooks to. The OpenClaw gateway itself can run anywhere - your office server, a cloud VM, even a Raspberry Pi - as long as that webhook URL reaches it.

The official OpenClaw Google Chat documentation has every config option, but I'll focus on the practical setup here.

Step-by-Step Setup

1. Create the Google Cloud Project and Service Account

Head to the Google Cloud Console and either create a new project or use an existing one. Enable the Google Chat API from the APIs & Services page.

Next, create a service account. Go to Credentials, click "Create Credentials," and pick "Service Account." Name it something sensible like openclaw-chat. You don't need to assign any special permissions at this stage - leave the permission and principal fields blank and just continue through.

Once the service account exists, go to its Keys tab, create a new JSON key, and download it. Store this file somewhere secure on your OpenClaw gateway host. Something like ~/.openclaw/googlechat-service-account.json works. This key is how OpenClaw authenticates when sending messages back to Google Chat.

2. Configure the Google Chat App

This part happens in the Google Chat API configuration page in the Cloud Console. You're creating the "app" that appears in Google Chat.

Fill in the basics:

• App name - whatever you want users to see. "AI Assistant" or your company name works.
• Avatar URL - a link to a square image for the bot's profile picture.
• Description - a short blurb users see when they add the app.

Under features:

• Enable Interactive features (required).
• Check Join spaces and group conversations if you want the bot in group chats, not just DMs.

Under connection settings:

• Select HTTP endpoint URL.
• Choose Use a common HTTP endpoint URL for all triggers.
• Enter your gateway's public URL followed by /googlechat. For example: https://your-domain.com/googlechat.

Under visibility:

• Check "Make this Chat app available to specific people and groups."
• Add your email address. You can add more users later.

Save, then refresh the page and change the App status to "Live - available to users." This step is easy to miss, and without it your bot won't appear in Google Chat searches.

3. Configure OpenClaw

Add the channel configuration to your OpenClaw config:

{
  channels: {
    googlechat: {
      enabled: true,
      serviceAccountFile: "/path/to/service-account.json",
      audienceType: "app-url",
      audience: "https://your-domain.com/googlechat",
      webhookPath: "/googlechat"
    }
  }
}

Or use environment variables: GOOGLE_CHAT_SERVICE_ACCOUNT_FILE=/path/to/service-account.json.

The audienceType and audience settings control how OpenClaw verifies incoming webhook requests. Google Chat sends a Bearer token with each request, and OpenClaw checks this token against your configured audience. Use app-url with your webhook URL as the audience for most setups. The alternative is project-number if you need to validate against the Cloud project number instead.

4. Start the Gateway

Run your OpenClaw gateway. Google Chat will start sending HTTP POST requests to your webhook path whenever someone messages the bot.

The Public URL Problem (And Three Good Solutions)

The one complication with Google Chat versus Slack is that you need a publicly reachable HTTPS endpoint. Google's servers need to POST webhook events to your gateway, and they can't reach localhost:18789.

Here are three approaches, ranked by how much I like them.

Tailscale Funnel (My Recommendation)

If you're running Tailscale (and if you're not, it's worth looking into for remote access), Funnel lets you expose a single path to the public internet while keeping everything else private on your tailnet.

# Expose only the webhook path publicly
tailscale funnel --bg --set-path /googlechat http://127.0.0.1:18789/googlechat

# Keep the dashboard private on the tailnet
tailscale serve --bg --https 8443 http://127.0.0.1:18789

Your public URL becomes https://your-node.your-tailnet.ts.net/googlechat. The OpenClaw dashboard stays at :8443 and is only accessible to machines on your tailnet. Nobody on the internet can reach your dashboard, admin API, or anything else.

I like this approach because it's minimal configuration, handles SSL automatically, and the security model is right by default - you expose exactly one path.

Reverse Proxy with Caddy

If you already have a domain and a reverse proxy, just route the webhook path:

your-domain.com {
    reverse_proxy /googlechat* localhost:18789
}

Caddy handles SSL via Let's Encrypt automatically. Requests to any path other than /googlechat get a 404. Simple and effective.

Cloudflare Tunnel

Configure your tunnel's ingress rules to only route /googlechat to localhost:18789. Set the default rule to return 404. This works well if you're already using Cloudflare for other things. For organisations already deployed on Cloudflare (like us at Team 400), this fits naturally into existing infrastructure.

Whichever option you choose, the security principle is the same: only expose the /googlechat webhook path to the internet. Keep your OpenClaw dashboard and other endpoints on a private network.

Finding and Adding the Bot in Google Chat

Once the gateway is running:

1. Open Google Chat.
2. Click the + icon next to Direct Messages.
3. Search for your bot by the app name you configured.

A note that catches people out: because this is a private app (not published to the Google Workspace Marketplace), it won't appear in the Marketplace browse list. You have to search for it by name, and only users listed in the visibility settings will find it.

Send "Hello" to trigger the first interaction. If the bot doesn't respond, check your gateway logs - the most common issue is a misconfigured webhook URL or audience setting.

Access Control - DMs and Spaces

Like the Slack integration, OpenClaw's Google Chat channel has sensible access control defaults.

DMs use pairing by default. When an unknown user messages the bot, they receive a pairing code. Someone with admin access needs to approve it:

openclaw pairing approve googlechat <code>

This prevents random people in your Google Workspace from chatting with your agent before you're ready. For controlled rollouts, pairing is the right default.

Spaces require @-mention by default. When your bot is added to a group space, it only responds when explicitly mentioned. This prevents the bot from jumping into every conversation uninvited - something that annoys people fast in group chats.

Session routing: DMs get their own session per user, and spaces get a session per space. This means conversation context stays separate. A question asked in the marketing space doesn't bleed into the finance space's conversation.

Targets in Google Chat use identifiers like users/<userId> for DMs and spaces/<spaceId> for spaces. If you're setting up allowlists, use these identifiers rather than email addresses - the email-based matching is deprecated and requires a specific config flag to enable.

Honest Assessment

Google Chat's webhook-based integration works well once it's set up, but the setup is more involved than Slack's Socket Mode. You're juggling Google Cloud Console settings, service account keys, and public URL configuration. Budget an hour for your first setup, maybe 30 minutes once you've done it before.

The Google Cloud Console UI for Chat app configuration is also a bit scattered. Settings are spread across multiple pages and it's not always clear which page you need. If something isn't working, double-check that you've set the app status to "Live" - that's the most common oversight.

On the positive side, once it's running, it's rock solid. Google's infrastructure delivers webhooks reliably, and the Bearer token verification means you can trust that incoming requests are genuinely from Google Chat.

For organisations building AI agent deployments across multiple channels, Google Chat fills a gap. Combined with OpenClaw's Slack, WhatsApp, Discord, and Telegram channels, you can reach people on whatever platform they prefer without building separate integrations for each one.

When to Choose Google Chat

If your organisation is on Google Workspace and your teams live in Google Chat, this is the right channel to start with. Don't force people into Slack just because the bot setup is slightly easier there.

If you're running a multi-channel deployment - maybe sales are on Slack but ops use Google Chat - OpenClaw handles both through the same gateway. Same agent, same configuration, different channels. The routing and session management just works.

For help planning a multi-channel AI agent deployment, we've done this for several Australian organisations and can walk you through the architecture decisions - which channels to prioritise, how to handle access control across platforms, and what the ongoing operational model looks like.