Google Chat API Deep Dive: Spaces, Pub/Sub Events, and the Google Workspace Moat

Google Chat in the Enterprise Landscape

Google Chat occupies an interesting position in the enterprise messaging landscape. As the primary messaging tool within Google Workspace (formerly G Suite), it has significant installed base — particularly among organizations that have standardized on Google's productivity suite. But compared to Slack and Microsoft Teams, its developer ecosystem is less mature and its API has historically been more restrictive.

For integration engineers building a bridge between Google Chat and other enterprise messaging platforms, this API landscape creates specific challenges that require understanding Google Chat's architectural choices.

The Event Delivery Model: Pub/Sub vs. Webhooks

Google Chat's event delivery architecture is fundamentally different from Slack and Teams. Google Chat uses Google Cloud Pub/Sub as its event delivery infrastructure, rather than a direct webhook to your endpoint.

The architecture:

A Google Chat App is created in the Google Cloud Console with event subscriptions configured
Google Chat publishes events to a Google Cloud Pub/Sub topic in your GCP project
Your integration layer subscribes to that Pub/Sub topic and pulls or receives events

This creates a dependency on Google Cloud infrastructure that does not exist for Slack or Teams integrations. To receive Google Chat events, your integration must:

Have a GCP project
Have Pub/Sub enabled on that project
Create and maintain Pub/Sub topics and subscriptions
Have IAM permissions configured to allow Google Chat to publish to your topic

For organizations that already use GCP, this is a manageable additional dependency. For organizations running on AWS or Azure, it requires maintaining a separate GCP footprint just for Google Chat event delivery.

The Chat REST API

In addition to Pub/Sub events, Google Chat provides a REST API for reading and writing messages. The API is part of the broader Google Workspace API ecosystem and authenticated via Google OAuth 2.0.

Authentication: Service Account vs. User OAuth

For a server-to-server messaging bridge, service account authentication is the appropriate model. A GCP service account is granted domain-wide delegation to impersonate users in the Google Workspace domain. This allows the bridge to post messages as specific users rather than as a bot.

The domain-wide delegation requirement is significant: it must be explicitly granted by a Google Workspace super admin. This creates an administrative friction that does not exist for Slack or Teams integrations.

Required API scopes for a messaging bridge:

https://www.googleapis.com/auth/chat.spaces — read Space (channel) information
https://www.googleapis.com/auth/chat.messages — read and send messages
https://www.googleapis.com/auth/chat.memberships — read Space membership (for identity mapping)

Spaces vs. Channels

Google Chat's data model uses the term "Space" rather than "Channel." A Space is analogous to a Slack channel or a Teams channel. The spaces.messages.create API method is the primary endpoint for posting a bridged message:

POST https://chat.googleapis.com/v1/spaces/{spaceName}/messages

Thread replies are handled via the thread.threadKey field — a developer-assigned string that serves as a stable identifier for a conversation thread:

{
  "text": "This is a threaded reply",
  "thread": {
    "threadKey": "syncrivo-thread-{sourceMessageId}"
  }
}

The threadKey approach is more ergonomic than Slack's thread_ts model because you can assign a stable, deterministic key at bridge time rather than looking up the parent message's timestamp.

Identity and User Management

Google Chat user identities are Google Account identities — each user has a Google Directory user ID and a primary email address. For sender attribution in bridged messages:

Resolve the source platform user's email address
Look up the Google Directory user ID via the Admin SDK users.get endpoint
Post the bridged message using the service account impersonating that user ID

This produces a message in Google Chat that appears to come from the actual employee, not from a bot — the same identity preservation that SyncRivo provides on the Teams and Slack sides.

The external user constraint

Google Chat Spaces can be configured as External Spaces (accessible to users outside the organization) or Internal Spaces. For a cross-company bridging scenario (bridging a vendor's Slack to your Google Chat), the destination Space must be configured as an External Space.

The External Space configuration requires explicit admin configuration and has different security properties than internal Spaces. For IT teams evaluating Google Chat bridging, this is an important prerequisite to verify before assuming external-to-internal bridging is possible.

Google Cards: The Adaptive Card Equivalent

Google Chat supports a rich message format called Cards — a JSON-based layout system similar to Slack Block Kit and Microsoft Adaptive Cards. For a formatted bridged message, the Cards V2 format is required:

{
  "cardsV2": [{
    "cardId": "bridged-message-card",
    "card": {
      "header": {
        "title": "Jordan Hayes",
        "subtitle": "via Microsoft Teams"
      },
      "sections": [{
        "widgets": [{
          "textParagraph": {
            "text": "Message content here"
          }
        }]
      }]
    }
  }]
}

The Cards format is well-documented, but the schema is distinct from both Adaptive Cards and Block Kit — translation between all three formats is a non-trivial mapping problem that requires explicit handling for each message type (plain text, file attachment, @mention, code block).

Rate Limits

The Google Chat API rate limits are generous by default and scale with Google Workspace tier. For standard Enterprise accounts:

Message creation: 30 requests per minute per Space
Space queries: 30 requests per minute

These limits are lower than Slack's Tier 4 (chat.postMessage) limits, but still adequate for most enterprise messaging bridge use cases. For organizations with very high-volume channels (>100 messages per minute in a single Space), the 30 RPM limit could become a bottleneck.

The Google Workspace Moat

The most significant integration constraint for Google Chat is the tight coupling to the Google Workspace ecosystem. Many of the advanced features that IT teams expect from enterprise messaging — user provisioning, SSO integration, DLP, retention policies — are configured and enforced at the Google Workspace level, not at the Chat level.

For a multi-platform environment where Microsoft 365 and Google Workspace coexist, this creates governance complexity: DLP policies must be configured separately in both Microsoft Purview and Google DLP. User provisioning is separate in Azure AD and Google Directory. Retention policies are separate in Microsoft Purview and Google Vault.

A well-designed messaging bridge does not attempt to unify these governance layers — it routes messages between platforms while respecting each platform's native governance configuration. This means the bridge must be aware of which channels have DLP scanning active on each side and ensure that bridging does not create a data path that bypasses DLP.

See Teams ↔ Google Chat integration → | Read the Google Workspace vs Microsoft 365 integration guide →