Für die Gmail API gelten Nutzungslimits, die die Häufigkeit einschränken, mit der Methoden der API aufgerufen werden können. Die Limits werden in Kontingenteinheiten definiert, einer abstrakten Maßeinheit für die Nutzung von Gmail-Ressourcen.
Gmail API-Kontingente
Es werden zwei Arten von Kontingenten erzwungen:
Pro Minute und Projekt:Dies ist die Anzahl der Kontingenteinheiten, die Ihr Google Cloud-Projekt in einer Minute verwenden kann.
Pro Minute, Nutzer und Projekt:Dies ist die Anzahl der Kontingenteinheiten, die ein bestimmter Nutzer in Ihrem Cloud-Projekt verwenden kann. Dieses Limit soll Ihnen helfen, eine faire Verteilung der Nutzung auf Ihre Nutzer zu gewährleisten.
In der folgenden Tabelle werden diese Limits näher erläutert:
| Nutzungslimit-Typ | Limit |
|---|---|
| Pro Minute und Projekt | 1.200.000 Kontingenteinheiten |
| Pro Minute, Nutzer und Projekt | 6.000 Kontingenteinheiten |
Informationen zum Beheben von Limit-Fehlern finden Sie unter Fehler beheben.
Täglicher Abrechnungsgrenzbetrag
Dieses Limit pro Tag und Projekt definiert die maximale Anzahl von Kontingenteinheiten, die Ihr Google Cloud-Projekt innerhalb eines 24-Stunden-Zeitraums verwenden kann, bevor Gebühren anfallen.
Bei einer Nutzung unter diesem Grenzwert fallen keine zusätzlichen Gebühren an und Ihr Google Cloud-Konto wird nicht belastet. Die vollständigen Abrechnungsdetails werden später im Jahr 2026 mitgeteilt, mindestens 90 Tage vor Inkrafttreten von Änderungen.
Eine Erhöhung dieses Tageslimit kann nicht beantragt werden.
In der folgenden Tabelle wird das Limit näher erläutert:
| Typ des Schwellenwertlimits | Limit |
|---|---|
| Pro Tag und Projekt | 80.000.000 Kontingenteinheiten |
Weitere Informationen finden Sie unter Standardisiertes Google Workspace-Modell für Agent-Tools und APIs.
Kontingentnutzung pro Methode
Die Anzahl der Kontingenteinheiten, die pro Anfrage verbraucht werden, hängt von der aufgerufenen Methode ab. In der folgenden Tabelle wird die Kontingenteinheitennutzung pro Methode beschrieben:
| Methode | Kontingenteinheiten |
|---|---|
drafts.create |
10 |
drafts.delete |
10 |
drafts.get |
20 |
drafts.list |
5 |
drafts.send |
100 |
drafts.update |
15 |
getProfile |
1 |
history.list |
2 |
labels.create |
5 |
labels.delete |
5 |
labels.get |
1 |
labels.list |
1 |
labels.update |
5 |
messages.attachments.get |
20 |
messages.batchDelete |
50 |
messages.batchModify |
50 |
messages.delete |
10 |
messages.get |
20 |
messages.import |
25 |
messages.insert |
25 |
messages.list |
5 |
messages.modify |
5 |
messages.send |
100 |
messages.trash |
20 |
messages.untrash |
5 |
settings.delegates.create |
100 |
settings.delegates.delete |
5 |
settings.delegates.get |
1 |
settings.delegates.list |
1 |
settings.filters.create |
5 |
settings.filters.delete |
5 |
settings.filters.get |
1 |
settings.filters.list |
1 |
settings.forwardingAddresses.create |
100 |
settings.forwardingAddresses.delete |
5 |
settings.forwardingAddresses.get |
1 |
settings.forwardingAddresses.list |
1 |
settings.getAutoForwarding |
1 |
settings.getImap |
1 |
settings.getPop |
1 |
settings.getVacation |
1 |
settings.sendAs.create |
100 |
settings.sendAs.delete |
5 |
settings.sendAs.get |
1 |
settings.sendAs.list |
1 |
settings.sendAs.update |
100 |
settings.sendAs.verify |
100 |
settings.updateAutoForwarding |
5 |
settings.updateImap |
5 |
settings.updatePop |
100 |
settings.updateVacation |
5 |
stop |
50 |
threads.delete |
20 |
threads.get |
40 |
threads.list |
10 |
threads.modify |
10 |
threads.trash |
20 |
threads.untrash |
10 |
watch |
100 |
Bei Verwendung der Gmail API gilt außerdem ein Limit von 500 Empfängern pro E‑Mail-Nachricht.
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 nicht erfolgreich sind, 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:
- Stellen Sie eine Anfrage an die Gmail API.
- Wenn die Anfrage fehlschlägt, wartet das System 1 +
random_number_millisecondsSekunden und wiederholt dann die Anfrage. - Wenn die Anfrage fehlschlägt, wartet das System 2 +
random_number_millisecondsSekunden und wiederholt dann die Anfrage. - Wenn die Anfrage fehlschlägt, wartet das System 4 +
random_number_millisecondsSekunden und wiederholt dann die Anfrage. - Und so weiter bis zur
maximum_backoff-Zeit. - 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), wobeinbei jeder Ausführung (Anfrage) um 1 erhöht wird. random_number_millisecondssteht 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 vonrandom_number_millisecondswird nach jeder Anfragewiederholung neu berechnet.maximum_backoffist 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.
Preise
Die Standardnutzung der Gmail API ist kostenlos. Wenn Sie die Kontingentanfragelimits überschreiten, fallen voraussichtlich später im Jahr 2026 Gebühren für Ihr Google Cloud-Rechnungskonto an. Weitere Informationen finden Sie unter Standardisiertes Google Workspace-Modell für Agent-Tools und APIs.
Kontingenterhöhung anfordern
Abhängig von der Ressourcennutzung Ihres Projekts können Sie eine Kontingentanpassung beantragen. API-Aufrufe durch 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: