Choosing an app style

Stay organized with collections Save and categorize content based on your preferences.

There are a number of different approaches to creating an app for Google Chat. Which is the most appropriate for your app depends on what your app will do, along with some technical constraints that might apply to your situation.

Interaction pattern

Start by identifying a suitable interaction pattern for your app. Here's a set of interaction patterns, in increasing order of complexity:

Pattern Description
Notifications only Apps in this category are not conversational; they simply inject messages (alarms, state change notifications, etc.) into a space.
Fetching data with simple commands These apps typically have a one-in, one-out message pattern. A message to the app triggers some kind of lookup and a response to send the resulting data into the space.
Starting external processes with simple commands The conversational complexity of these apps depend on the nature of the process they initiate. Typically these respond synchronously to a command, but also inject asynchronous updates as a result of process execution.
Smart agents that combine internal systems together These are the most complex of apps, often involving NLP and integration with multiple external systems.

Endpoint type

Depending on the usage pattern and your deployment needs, you also need to decide on an endpoint type. Here's a summary of endpoint types and their suggested uses:

Endpoint type Pub? Application Authentication
Incoming webhook Not a true endpoint, but a simple way to build one-off notifiers that are "hardwired" to a specific chat room. None
Apps Script Straightforward way to build a simple app for yourself, team, or domain. None
Synchronous HTTP Easy way to build an app that you want the world to use, if the app never needs to respond asynchronously. None
Asynchronous HTTP Standard way to build an app that you want the world to use. Service account
Cloud Pub/sub Best for connecting to an internal system that is behind a firewall. Service account

Additional considerations

This section lists the main things you should consider when defining how your app will work with Google Chat. These are described in detail in following sections.

Security

There may be security mechanisms you need to accommodate when connecting your app implementation to Google Chat:

  • Is your app's implementation behind a firewall? Use a Cloud Pub/Sub endpoint.
  • Does your app's HTTP endpoint use OAuth?
  • Does your app's implementation need to access protected resources? You'll need to set up third-party authentication.
  • Will your app send unsolicited messages? Your app will need a service account.

Publishability

If you want to publish your app in the Google Workspace Marketplace, you will need to use an HTTP or Cloud Pub/Sub endpoint.

If you just want a quick app for you or your workgroup to use, and you're not using an existing remote implementation, you can write the app directly in Apps Script. This doesn't require any authentication (since Apps Scripts always run in the context of an authorized user).

Service accounts

Apps that asynchronously inject messages do so using the Google Chat REST API. To make calls the this API, apps must authenticate using a service account.

Some apps don't fall into this category:

  • Apps Script apps
  • Incoming webhooks notifiers
  • Simple, synchronous HTTP apps that only send information back in the HTTP POST response.

Simple synchronous HTTP apps

Other types of apps

All other apps, unless they are implemented in Apps Script, need to use service accounts so that they can authenticate their inbound messages.

System architectures

This section describes several of the key architectures used to implement chat apps for Google Chat, using the endpoint types described above.

Simple notifier

The simple notifier is not a conversational chat app, and doesn't support messages from users to the app. It simply allows an application to inject messages into a chat room.

Diagram showing an incoming webhook sending a message to a space

This pattern uses an incoming webhook to inject messages into the space. It does not use a developer console project or a service account, so it cannot be published and added to various spaces. However, for one-off notifiers built for a single Chat space, it is quick to implement.

Basic synchronous HTTP

This is the standard architecture for a one-in, one-out conversational app. It doesn't use a service account; this is because its responses are always carried by the HTTP response to the originating HTTP POST message.

Diagram showing a synchronous HTTP app response

Many simple apps can be implemented using this architecture, and they can be registered so that they can be discovered and added to other chat rooms.

Asynchronous HTTP

This pattern allows HTTP-based apps to respond asynchronously to user messages or other triggers.

Diagram showing an asynchronous HTTP app response

This pattern is slightly more complex to set up than the synchronous version, but is adaptable to a large range of app requirements.

Cloud Pub/Sub

This pattern is well suited to systems where the app implementation is behind a firewall. Instead of Google Chat attempting to traverse the firewall, part of the implementation is an event subscriber and "pulls" the messages from the Pub/Sub topic.

Diagram showing an app receiving a request through a firewall with Google Pub/Sub

Note that there is no mechanism for responding through the Pub/Sub mechanism. The app must respond asynchronously in the same way as the async HTTP pattern.