Nutzungsbeschränkungen

Da die Google Chat API ein freigegebener Dienst ist, wenden wir Kontingente und Beschränkungen an, um sicherzustellen, dass sie von allen Nutzern fair verwendet wird, und um die Gesamtleistung von Google Workspace zu schützen.

Wenn Sie ein Kontingent überschreiten, erhalten Sie eine Antwort mit dem HTTP-Statuscode 429: Too many requests. Zusätzliche Ratenlimitprüfungen im Chat-Back-End können ebenfalls dieselbe Fehlermeldung auslösen. Wenn dieser Fehler auftritt, sollten Sie einen exponentiellen Backoff-Algorithmus verwenden und es später noch einmal versuchen. Solange Sie die in den folgenden Tabellen aufgeführten Kontingente pro Minute nicht überschreiten, ist die Anzahl der Anfragen, die Sie pro Tag senden können, nicht begrenzt.

Für Chat API-Methoden können mehrere Kontingenttypen gelten: Kontingente pro Projekt, pro Bereich und pro Nutzer.

Kontingente pro Projekt

Kontingente pro Projekt begrenzen die Rate der Abfragen für ein Google Cloud-Projekt und gelten daher für eine einzelne Chat-App, die die angegebenen Chat API-Methoden für jedes Kontingent aufruft.

In der folgenden Tabelle sind die Abfragelimits pro Projekt aufgeführt. Sie finden diese Limits auch auf der Seite Kontingente.

Kontingent pro Projekt

Chat API-Methoden

Limit (pro 60 Sekunden)

Schreibvorgänge für Nachrichten pro Minute

spaces.messages.create

spaces.messages.patch

spaces.messages.delete

3000

Lesevorgänge für Nachrichten pro Minute

spaces.messages.get

spaces.messages.list

3000

Schreibvorgänge für Mitgliedschaften pro Minute

spaces.members.create

spaces.members.delete

300

Lesevorgänge für Mitgliedschaften pro Minute

spaces.members.get

spaces.members.list

3000

Schreibvorgänge für Bereiche pro Minute

spaces.setup

spaces.create

spaces.patch

spaces.delete

60

Lesevorgänge für Bereiche pro Minute

spaces.get

spaces.list

spaces.findDirectMessage

3000

Schreibvorgänge für Anhänge pro Minute

media.upload

600

Lesevorgänge für Anhänge pro Minute

spaces.messages.attachments.get

media.download

3000

Schreibvorgänge für Reaktionen pro Minute

spaces.messages.reactions.create

spaces.messages.reactions.delete

600

Lesevorgänge für Reaktionen pro Minute

spaces.messages.reactions.list

3000

Schreibvorgänge für benutzerdefinierte Emojis pro Minute

customEmojis.create

customEmojis.delete

600

Lesevorgänge für benutzerdefinierte Emojis pro Minute

customEmojis.get

customEmojis.list

3000

Schreibvorgänge für Abschnitte pro Minute

users.sections.create

users.sections.delete

users.sections.patch

users.sections.position

users.sections.items.move

600

Lesevorgänge für Abschnitte pro Minute

users.sections.list

users.sections.items.list

3000

Lesevorgänge für Verfügbarkeit pro Minute

users.availability.get

3000

Schreibvorgänge für Verfügbarkeit pro Minute

users.availability.update

users.availability.markAsActive

users.availability.markAsAway

users.availability.markAsDoNotDisturb

3000

Kontingente pro Bereich

Kontingente pro Bereich begrenzen die Rate der Abfragen in einem bestimmten Bereich und werden von allen Chat-Apps gemeinsam genutzt, die in diesem Bereich aktiv sind und die aufgeführten Chat API-Methoden für jedes Kontingent aufrufen.

In der folgenden Tabelle sind die Abfragelimits pro Bereich aufgeführt:

Kontingent pro Bereich

Chat API-Methoden

Limit (pro Sekunde)

Lesevorgänge pro Sekunde

media.download

spaces.get

spaces.members.get

spaces.members.list

spaces.messages.get

spaces.messages.list

spaces.messages.attachments.get

spaces.messages.reactions.list

15

Schreibvorgänge pro Sekunde

media.upload

spaces.delete

spaces.patch

spaces.messages.create (Für eingehende Webhooks gelten zusätzliche Limits)

spaces.messages.delete

spaces.messages.patch

spaces.messages.reactions.delete

1

Schreibvorgänge für das Erstellen von Reaktionen pro Sekunde

spaces.messages.reactions.create

5

Schreibvorgänge für Nachrichten pro Sekunde beim Importieren von Daten in Google Chat

spaces.messages.create

10

Kontingente pro Nutzer

Kontingente pro Nutzer begrenzen die Rate der Abfragen für einen Google Chat-Nutzer. Abfragen beziehen sich auf alle Chat-Apps, die eine Chat API-Methode im Namen eines Nutzers aufrufen (mit Nutzerauthentifizierung).

In der folgenden Tabelle sind die Abfragelimits pro Nutzer aufgeführt:

Kontingent pro Nutzer

Chat API-Methoden

Limit (pro Sekunde)

Schreibvorgänge für benutzerdefinierte Emojis pro Sekunde

customEmojis.create

customEmojis.delete

1

Lesevorgänge für benutzerdefinierte Emojis pro Sekunde

customEmojis.get

customEmojis.list

15

Schreibvorgänge pro Sekunde

users.sections.create

users.sections.delete

users.sections.patch

users.sections.position

users.sections.items.move

users.availability.update

users.availability.markAsActive

users.availability.markAsAway

users.availability.markAsDoNotDisturb

1

Lesevorgänge pro Sekunde

users.sections.list

users.sections.items.list

users.availability.get

15

Zusätzliche Nutzungslimits

Hoher API-Traffic, der auf denselben Bereich ausgerichtet ist, kann zusätzliche interne Limits auslösen, die auf der Kontingente-Seite nicht sichtbar sind.

Zeitbasierte Kontingentfehler beheben

Bei allen zeitbasierten Fehlern (maximal N Anfragen pro X Minuten) empfehlen wir Ihnen, dass Ihr Code die Ausnahme abfängt und einen abgeschnittenen exponentiellen Backoff verwendet, um zu verhindern, dass Ihre Geräte eine übermäßige Last erzeugen.

Exponentielle Backoffs bilden eine Standard-Fehlerbehandlungsstrategie für Netzwerkanwendungen. Ein exponentieller Backoff-Algorithmus wiederholt Anfragen mit exponentiell zunehmenden Wartezeiten zwischen den Anfragen bis zur maximalen Backoff-Zeit. Wenn Anfragen weiterhin nicht erfolgreich sind, müssen die Verzögerungen zwischen den Anfragen mit der Zeit zunehmen, bis die Anfrage erfolgreich ist.

Beispielalgorithmus

Ein exponentieller Backoff-Algorithmus wiederholt Anfragen exponentiell und verlängert dabei die Wartezeit zwischen zwei Wiederholungen bis zur maximalen Backoff-Zeit. Beispiel:

  1. Senden Sie eine Anfrage an die Google Chat API.
  2. Wenn die Anfrage fehlschlägt, warten Sie 1 + random_number_milliseconds und wiederholen Sie die Anfrage.
  3. Wenn die Anfrage fehlschlägt, warten Sie 2 + random_number_milliseconds und wiederholen Sie die Anfrage.
  4. Wenn die Anfrage fehlschlägt, warten Sie 4 + random_number_milliseconds und wiederholen Sie die Anfrage.
  5. Und so weiter bis zur maximum_backoff-Zeit.
  6. Warten Sie weiter und wiederholen Sie den Vorgang bis zu einer maximalen Anzahl von Wiederholungen, verlängern Sie aber nicht die Warte zeit zwischen den Wiederholungen.

Dabei gilt:

  • Die Wartezeit beträgt min(((2^n)+random_number_milliseconds), maximum_backoff), wobei n für jede Iteration (Anfrage) um 1 erhöht wird.
  • random_number_milliseconds ist eine zufällige Anzahl von Millisekunden,die kleiner oder gleich 1.000 ist. So lassen sich Situationen vermeiden, in denen viele Clients synchronisiert werden durch eine Situation und alle gleichzeitig Anfragen wiederholen und diese in synchronisierten Wellen senden. Der Wert von random_number_milliseconds wird nach jeder Anfragewiederholung neu berechnet.
  • maximum_backoff ist normalerweise 32 oder 64 Sekunden lang. Der geeignete Wert hängt vom jeweiligen Anwendungsfall ab.

Der Client kann den Vorgang wiederholen, nachdem er die maximum_backoff-Zeit erreicht hat. Die Backoff-Zeit muss dabei nicht mehr verlängert werden. Wenn ein Client beispielsweise eine maximum_backoff-Zeit von 64 Sekunden verwendet, kann er nach Erreichen dieses Werts alle 64 Sekunden eine Wiederholung versuchen. Irgendwann sollten Clients daran gehindert werden, den Vorgang unbegrenzt zu wiederholen.

Die Wartezeit zwischen den Wiederholungen und der Anzahl der Wiederholungen hängt von Ihrem Anwendungsfall und den Netzwerkbedingungen ab.

Kontingenterhöhung pro Projekt anfordern

Abhängig von der Ressourcennutzung Ihres Projekts können Sie eine Kontingentanpassung anfordern. API-Aufrufe durch ein Dienstkonto gelten als Nutzung eines einzelnen Kontos. Wenn Sie ein angepasstes Kontingent beantragen, bedeutet dies nicht, dass Ihr Antrag auch genehmigt wird. Bei Anfragen zur Kontingentanpassung, die den Kontingentwert erheblich erhöhen würden, kann die Genehmigung länger dauern.

Es gelten nicht für alle Projekte dieselben Kontingente. Wenn Sie Google Cloud im Laufe der Zeit häufiger nutzen, müssen Ihre Kontingentwerte möglicherweise erhöht werden. Falls Sie eine deutlich stärkere Auslastung erwarten, können Sie proaktiv eine Anpassung Ihres Kontingents anfordern auf der Seite Kontingente und Systemlimits der Google Cloud Console.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Kontingente für den Chat MCP-Server

Der Chat MCP-Server verwendet eine Messwertzuweisung für Abfragekosten. In den folgenden Tabellen sind die Abfragekosten für jede Chat MCP-Servermethode nach Abschnitt aufgeführt:

Chat MCP-Kontingente

Es werden zwei Arten von Kontingenten erzwungen:

  • Pro Minute und Projekt:Dies sind die Abfragekosten für Ihr Google Cloud-Projekt für eine Minute.

  • Pro Minute, Nutzer und Projekt:Dies sind die Abfragekosten für Ihr Google Cloud-Projekt für eine Minute, die ein bestimmter Nutzer verwenden kann. Mit diesem Limit können Sie eine faire Verteilung der Nutzung auf Ihre Nutzer gewährleisten.

In der folgenden Tabelle sind diese Kontingente aufgeführt:

Nutzungslimittyp Abfragekosten
Pro Minute und Projekt 3.000
Pro Minute, Nutzer und Projekt 300

Chat MCP-Toolsets

In der folgenden Tabelle sind die Abfragekosten für jedes chatmcp.googleapis.com-Toolset aufgeführt:

Endpunkt

Tool

Abfragekosten

/mcp/v1

list_messages

1

search_conversations

10

search_messages

10

send_message

10

Weitere Informationen finden Sie in der Chat MCP API Referenz.