Nutzungsbeschränkungen

Da die Google Chat API ein gemeinsamer Dienst ist, wenden wir Kontingente und Einschrä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-Backend können ebenfalls dieselbe Fehlermeldung generieren. 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, gibt es keine Begrenzung für die Anzahl der Anfragen, die Sie pro Tag stellen können.

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 Anfragen 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

Gelesene Nachrichten pro Minute

spaces.messages.get

spaces.messages.list

3000

Nachrichtensuchen pro Minute

spaces.messages.search

300

Mitgliedschaft – Schreibvorgänge pro Minute

spaces.members.create

spaces.members.delete

300

Mitgliedschaft – Lesevorgänge pro Minute

spaces.members.get

spaces.members.list

3000

Schreibvorgänge pro Minute im Gruppenbereich

spaces.setup

spaces.create

spaces.patch

spaces.delete

60

Lesevorgänge pro Minute für Bereiche

spaces.get

spaces.list

spaces.findDirectMessage

spaces.search

3000

Leseanfragen für die Suche in Gruppenbereichen pro Minute (ohne Administratorberechtigungen)

spaces.search

300

Anhang – Schreibvorgänge pro Minute

media.upload

600

Anhanglesevorgänge pro Minute

spaces.messages.attachments.get

media.download

3000

Reaktionsschreibvorgänge pro Minute

spaces.messages.reactions.create

spaces.messages.reactions.delete

600

Reaktionslesevorgänge pro Minute

spaces.messages.reactions.list

3000

CustomEmoji-Schreibvorgänge pro Minute

customEmojis.create

customEmojis.delete

600

CustomEmoji-Lesevorgänge pro Minute

customEmojis.get

customEmojis.list

3000

Abschnitt – Schreibvorgänge pro Minute

users.sections.create

users.sections.delete

users.sections.patch

users.sections.position

users.sections.items.move

600

Abschnittslesevorgänge pro Minute

users.sections.list

users.sections.items.list

3000

Verfügbarkeitslesevorgänge pro Minute

users.availability.get

3000

Verfügbarkeit – Schreibvorgänge pro Minute

users.availability.update

users.availability.markAsActive

users.availability.markAsAway

users.availability.markAsDoNotDisturb

3000

Kontingente pro Bereich

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

In der folgenden Tabelle sind die Abfragelimits pro Arbeitsbereich 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 Reaktionen pro Sekunde

spaces.messages.reactions.create

5

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

spaces.messages.create

10

Kontingente pro Nutzer

Kontingente pro Nutzer beschränken die Rate der Anfragen für einen Google Chat-Nutzer. Anfragen beziehen sich auf alle Chat-Apps, die im Namen eines Nutzers eine Chat API-Methode 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 pro Sekunde für benutzerdefinierte Emojis

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 Seite Kontingente nicht sichtbar sind.

Zeitbasierte Kontingentfehler beheben

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

Exponentieller Backoff ist eine Standardstrategie zur Fehlerbehandlung für Netzwerkanwendungen. Ein exponentieller Backoff-Algorithmus wiederholt Anfragen mit exponentiell zunehmenden Wartezeiten zwischen den Anfragen bis zur maximalen Backoff-Zeit. Wenn Anfragen weiterhin fehlschlagen, ist es wichtig, dass 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. Stellen Sie eine Anfrage an die Google Chat API.
  2. Wenn die Anfrage fehlschlägt, wartet das System 1 + random_number_milliseconds Sekunden und wiederholt dann die Anfrage.
  3. Wenn die Anfrage fehlschlägt, wartet das System 2 + random_number_milliseconds Sekunden und wiederholt dann die Anfrage.
  4. Wenn die Anfrage fehlschlägt, wartet das System 4 + random_number_milliseconds Sekunden und wiederholt dann die Anfrage.
  5. Und so weiter bis zur maximum_backoff-Zeit.
  6. Das System wartet weiter und führt erneute Versuche bis zu einer maximalen Anzahl an Wiederholungsversuchen aus, jedoch ohne den zeitlichen Abstand zwischen zwei Versuchen zu erhöhen.

Dabei gilt:

  • Die Wartezeit beträgt min(((2^n)+random_number_milliseconds), maximum_backoff), wobei n bei jeder Ausführung (Anfrage) um 1 erhöht wird.
  • random_number_milliseconds steht für eine zufällige Anzahl von Millisekunden,deren Wert größer oder gleich 1.000 ist. So lassen sich Situationen vermeiden, in denen viele Clients synchronisiert werden 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 den Vorgang nach Erreichen dieses Werts alle 64 Sekunden noch einmal versuchen. Sie sollten jedoch dafür sorgen, dass er dies nicht unbegrenzt tut.

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

Kontingenterhöhung pro Projekt anfordern

Abhängig von der Ressourcennutzung Ihres Projekts möchten Sie möglicherweise eine Kontingentanpassung beantragen. API-Aufrufe über ein Dienstkonto werden als Nutzung eines einzelnen Kontos betrachtet. Wenn Sie ein angepasstes Kontingent beantragen, bedeutet dies nicht, dass Ihr Antrag auch genehmigt wird. Die Genehmigung von Anfragen zur Kontingentanpassung, die den Kontingentwert erheblich erhöhen würden, kann 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 auf der Seite Kontingente und Systemlimits der Google Cloud Console eine Anpassung Ihres Kontingents anfordern.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Chat-MCP-Serverkontingente

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

Kontingente für Chat-MCP

Es werden zwei Arten von Kontingenten erzwungen:

  • Pro Minute und Projekt:Das 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.

In der folgenden Tabelle werden diese Kontingente näher erläutert:

Nutzungslimit-Typ Abfragekosten
Pro Minute und Projekt 3.000
Pro Minute, Nutzer und Projekt 300

Kontingente für das Chat-MCP-Toolset

In der folgenden Tabelle sind die Abfragekosten für die einzelnen chatmcp.googleapis.com-Toolsets 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.