Updates

Google Chat allows you to set the default Markdown syntax for your application

Abstract message cards arranged through a transparent formatting filter
Illustration: Abstract message cards arranged through a transparent formatting filter

Google announced on 16 October that developers can set a default formatting syntax for a Google Chat app. The option is on the Chat API configuration page in the Google Cloud Console, and the deployment is expected to be completed in a few days. You can choose between the standard Markdown syntax or the original Google Chat syntax. This is a change in the way messages are presented, not the launch of a new AI model.

The update is also relevant for those running an AI agent or integration that publish summaries, alerts, and tasks in Chat. When the message is generated automatically, it is useful to know what syntax the service expects to receive. An app-level default can make messages more consistent, but does not itself guarantee accurate text or that every formatting element appears as intended.

What changed in the setting

According to Google, it is also possible to override the default at a single request level using the markupSyntax field in the Message resource. The option is relevant for creating, updating, or reading messages using the API. Therefore, it is not necessary to apply that syntax to every scenario. A team with existing messages can look at how to combine the default with requests that require explicit behavior differently.

It is worth distinguishing between the availability of the new definition and Markdown support in general. The current update deals with the application-level default and the ability to control it on any request. It does not mean every existing app has been converted automatically, or describe a change in its permissions to access conversation content. It also does not announce any price changes or extended caps on the use of models.

What to look for in an existing integration

Before changing an active application, it is advisable to try messages that represent actual usage: lists, code snippets, highlights, and text including Hebrew and English. Long messages and messages that are updated after publication should also be checked. It's a check of your integration, not an absolute confirmation that any text that a model generates will be valid in any Chat client or any display format.

If an agent summarizes an appointment or produces tasks, it is advisable to separately check the content and the presentation. An orderly message can appear credible even when the number, name, or date is incorrect. Changing the design syntax does not replace the approval or control processes required by the agent. It allows for a clearer definition of how the message should be decoded and displayed in the service.

The practical step is to check the app-page setting, record the default and identify requests that send an explicit override. This makes it easier to understand a gap between messages without immediately attributing it to the model that produces them. For a team running several automated processes, separating text generation from formatting can make troubleshooting and later maintenance easier.