Google Chat and Microsoft Teams Channels
Purpose and Scope
Google Chat and Microsoft Teams channels let a Flue application receive authenticated collaboration events and route them into agents, workflows, or ordinary application handlers. A channel is the ingress boundary: it verifies a provider request, parses it into provider-native data, and calls the application callback. The application then decides whether to dispatch an agent, invoke business logic, or return a provider-specific response. This page focuses on the first-party Google Chat and Teams integrations, how their route modules fit Flue discovery, and where outbound messaging remains application-owned rather than hidden inside the channel package.
Sources: apps/docs/src/content/docs/guide/channels.md, packages/google-chat/README.md, packages/teams/README.md
The important design rule is ownership separation. Flue channel packages own inbound HTTP concerns such as authentication, handshake behavior, body parsing, and route discovery below the channel namespace. Your project owns provider clients, credentials for outbound requests, durable business state, deduplication, authorization policy, and the tools exposed to agents. This boundary is especially useful for Google Chat and Teams because both ecosystems have broad outbound APIs. Flue verifies and normalizes the callback edge while your project keeps the narrowly scoped client code it actually needs.
Sources: apps/docs/src/content/docs/guide/channels.md, packages/google-chat/README.md, packages/teams/README.md
Relevant Source Files
- apps/docs/src/content/docs/guide/channels.md — Defines the general Flue channel model, the route discovery convention for files under the channels directory, the named channel and client export pattern, and the ownership split between channel packages and application code.
- packages/google-chat/README.md — Documents the public Google Chat channel entry point, discovered routes, authentication modes, callback payload shape, body limit behavior, conversation-key semantics, and explicit non-goals for outbound clients and deduplication.
- packages/teams/README.md — Documents the public Teams channel entry point, discovered route, Bot Connector token validation, provider-native Activity handling, destination derivation, conversation keys, and explicit non-goals for outbound clients and deduplication.
- packages/google-chat/package.json — Identifies the package as @flue/google-chat, its exported module shape, supported runtime engine, and dependencies used by the channel package.
- packages/teams/package.json — Identifies the package as @flue/teams, its exported module shape, supported runtime engine, and dependencies, including Bot Framework schema types and token verification support.
Discovery and Route Placement
Flue discovers channel modules by filename. Each immediate file in the project channels directory exports a named channel binding, and that filename defines the route namespace below the mounted Flue application. For these integrations, the conventional modules are a Google Chat file and a Teams file. The Google Chat package serves the direct interaction callback at the interactions route and can also serve an optional Workspace Events route. The Teams package serves Bot Connector activities on its activities route. Mounting still follows the application’s broader routing configuration, so these paths are relative to the Flue mount.
Sources: apps/docs/src/content/docs/guide/channels.md, packages/google-chat/README.md, packages/teams/README.md
A typical generated module also exports ordinary application code beside the channel binding. The general channel guide shows this as a named client export initialized with the provider’s SDK or REST client. The Google Chat and Teams blueprints follow the same idea but intentionally create narrow Fetch clients for outbound messaging instead of requiring heavyweight hosting SDKs. The named channel export is what Flue uses for ingress. The named client, message tool, helpers, and authorization decisions are part of your application and can be edited to match the project’s security model.
Sources: apps/docs/src/content/docs/guide/channels.md, packages/google-chat/README.md, packages/teams/README.md
Google Chat Flow
Use the Google Chat blueprint when a Flue project needs authenticated Chat app interactions, optional Workspace Events delivery, and project-owned replies back into Chat. The package entry point is createGoogleChatChannel from @flue/google-chat. Direct interactions are configured with an interactions object that includes authentication and a handler. Endpoint URL authentication constrains the OIDC audience to the configured app URL, while the package also documents support for the legacy project-number certificate mode. The handler receives the Hono context and a verified payload that preserves Google Chat field names, nesting, discriminants, and unknown fields.
Sources: packages/google-chat/README.md, packages/google-chat/package.json
The common application flow is to accept only message interactions that can be mapped to a Google Chat space and optional thread, derive a conversation key, and dispatch the relevant agent with a provider-specific input envelope. Non-message interactions can be acknowledged without agent work. The package’s conversation keys identify spaces and optional threads, and the documentation calls out that a thread must belong to its space. Treat those keys as routing identities, not authorization capabilities. The package is stateless and does not deduplicate interaction identifiers or Pub/Sub event identifiers, so production systems should persist delivery decisions when duplicate processing matters.
Sources: packages/google-chat/README.md
Google Chat Workspace Events use a separate optional route for authenticated Pub/Sub push. That callback receives the delivery wrapper rather than only a decoded business event, preserving message metadata, CloudEvent attributes, encoded data, and delivery attempt information for application-owned decoding. This is useful when the application needs to preserve Google’s envelope for auditing, retries, or custom event selection. Request bodies are stream-limited by default, and callbacks may return JSON, a Fetch or Hono response, or no value for an empty successful response. Exceptions continue through Hono’s normal error handling.
Sources: packages/google-chat/README.md
Microsoft Teams Flow
Use the Teams blueprint when a Flue project needs authenticated Microsoft Bot Connector activity ingress and controlled outbound replies through a project-owned client. The package entry point is createTeamsChannel from @flue/teams. The channel is configured with the application identifier, tenant identifier, and an activities callback. The package validates Bot Connector bearer tokens against Microsoft OpenID metadata and endorsed signing keys, then checks audience, issuer, expiry, channel endorsement, exact service URL, and tenant before handing the application the provider-native Activity unchanged.
Sources: packages/teams/README.md, packages/teams/package.json
The callback should switch on the native activity type rather than expecting Flue to convert Teams into a generic chat event. Message activities, conversation updates, invokes, reactions, and other Bot Framework types remain Bot Framework activities. For message dispatch, derive the canonical routing identity with the channel destination helper, then use the channel conversation key to continue the same agent instance for that Teams conversation or thread. This keeps agent continuity aligned with Teams’ own conversation structure while preserving the full activity object for application-specific fields, mentions, tenant information, and entities.
Sources: packages/teams/README.md
Teams outbound messaging is intentionally not bundled into the channel package. The package documentation states that it does not include an outbound Teams client, OAuth credential storage, installation flow, or model tools. The blueprint instead creates editable project code that uses Fetch over Microsoft OAuth and Bot Connector REST protocols. That choice keeps the integration usable on both Node and Cloudflare-style Fetch runtimes and avoids binding Flue applications to Microsoft’s Node-oriented hosting SDKs. Your generated tool should restrict what the agent may send and should verify that replies target the intended conversation identity.
Sources: packages/teams/README.md, packages/teams/package.json
Compact Reference
| Integration | Package | Discovered module | Inbound route | Main callback | Authentication and validation | Application-owned responsibilities |
|---|---|---|---|---|---|---|
| Google Chat | @flue/google-chat | channels/google-chat.ts | POST /channels/google-chat/interactions and optional POST /channels/google-chat/events | interactions.handler or events callback | Endpoint URL OIDC authentication, legacy project-number certificate mode, authenticated Pub/Sub push for events | Service-account client, outbound Chat REST calls, message tool, deduplication, subscription management, authorization policy |
| Microsoft Teams | @flue/teams | channels/teams.ts | POST /channels/teams/activities | activities callback | Bot Connector bearer token validation, endorsed keys, audience, issuer, expiry, channel endorsement, exact service URL, tenant check | OAuth client credentials, outbound Bot Connector calls, installation flow, model tools, deduplication, authorization policy |
Setup and Next Steps
Start from the blueprint commands for an existing project: add the Google Chat channel when the app is registered as a Chat app, or add the Teams channel when the app is registered as a Teams bot. Review the generated channel module before deployment. Confirm environment variables, route URLs, provider app settings, and outbound credentials. Then test a valid provider request, an invalid signature or token, a non-message event, and the agent dispatch path. Because both packages are stateless, add durable deduplication and audit records in application storage when external delivery retries could create duplicate actions.
Sources: apps/docs/src/content/docs/guide/channels.md, packages/google-chat/README.md, packages/teams/README.md
For broader context, read the Channels guide before editing generated modules, then follow the routing and agent API references when connecting callbacks to durable work. If an agent should reply, expose a small tool that uses the generated provider client and enforces the project’s permission rules. If the project runs on more than one target, test the same channel under the intended Node or Cloudflare runtime because these packages are designed around Fetch-compatible behavior and the package manifests declare the published entry points and runtime requirements.
Sources: apps/docs/src/content/docs/guide/channels.md, packages/google-chat/package.json, packages/teams/package.json