E-Mail-API Rate Limits: Provider-Vergleich

Befehlsreferenzen: nylas email list, nylas email send, nylas email search.

Welche Rate Limits gelten für die Gmail API?

Die Gmail API misst Rate Limits in Quota-Einheiten, nicht in reinen Request-Zahlen. Jede Gmail-API-Methode kostet eine andere Anzahl Einheiten, und jeder Nutzer erhält standardmäßig 250 Einheiten pro Sekunde. Ein messages.list-Aufruf kostet 5 Einheiten, ein messages.get kostet 5 Einheiten und ein messages.send kostet 100 Einheiten. Sie können also pro Nutzer höchstens 2 Nachrichten pro Sekunde senden, aber 50 Seiten pro Sekunde auflisten.

Laut Googles Gmail-API-Quota-Dokumentation wurde das Pro-Nutzer-Limit am 1. Mai 2026 auf 250 Einheiten/Nutzer/Sekunde aktualisiert (zuvor wurden nur Tageskontingente erfasst). Das tägliche Limit pro Projekt liegt bei 1 Milliarde Quota-Einheiten. Wird eines von beiden überschritten, antwortet die API mit HTTP 429 und einem Retry-After-Header.

Das Quota-Einheiten-System bedeutet: Eine naive Sync-Schleife, die messages.list und anschließend messages.get für jedes Ergebnis aufruft, verbraucht 10 Einheiten pro Nachricht. 1.000 Nachrichten zu synchronisieren kostet insgesamt 10.000 Einheiten — ein einzelner Nutzer kann das in 40 Sekunden aufbrauchen. Batch-Endpunkte reduzieren den Roundtrip-Overhead, ändern aber nichts an den Einheiten-Kosten pro Nachricht. Das CLI bündelt diese Aufrufe intern und respektiert Retry-After-Header, sodass ein nylas email list --limit 1000-Aufruf Pagination und Throttling ohne zusätzlichen Code abwickelt.

# List up to 200 Gmail messages — the CLI handles pagination and rate limits
nylas email list --limit 200 --json

Welche Rate Limits gelten für E-Mails in Microsoft Graph?

Microsoft Graph erzwingt pro App und Postfach ein Throttling von 10.000 Requests pro 10 Minuten. Das entspricht rund 16 Requests pro Sekunde und Postfach. Beim Überschreiten des Limits gibt Graph HTTP 429 mit einem Retry-After-Header zurück, der die Wartezeit in Sekunden angibt. Anders als Gmail verwendet Graph kein System mit Kosten pro Methode; jeder Request zählt als 1, unabhängig von der Komplexität des Endpunkts.

Laut Microsofts Graph-API-Throttling-Dokumentation gilt das Limit von 10.000/10 Min. für die Outlook-Endpunkte für Mail, Kalender und Kontakte. Mandantenweite Limits liegen höher (nicht offengelegt, serviceabhängig). Batch-Requests über den $batch-Endpunkt zählen für das Throttling als 1 Request, sind aber auf 20 Operationen pro Batch begrenzt. Die praktische Obergrenze für Mail-Sync liegt bei etwa 3.200 Nachrichten pro 10 Minuten, wenn jede Nachricht ein separates GET benötigt.

Graph setzt außerdem ein Sendelimit von 10.000 Empfängern pro Tag für Microsoft-365-Business-Konten und 300 Nachrichten pro Tag für Outlook.com-Consumer-Konten. Entscheidend ist die Zahl der Empfänger, nicht die der Nachrichten. Eine einzelne Nachricht an 50 Empfänger zählt mit 50 gegen das Tageslimit.

Das CLI abstrahiert diese Limits hinter einem einzigen Befehl. Führen Sie nylas email send gegen ein Outlook-Postfach aus, behandelt das CLI 429-Antworten automatisch und wiederholt mit der im Retry-After-Header angegebenen Verzögerung.

# Send an email through Outlook — retries on 429 are handled by the CLI
nylas email send --to "recipient@example.com" --subject "Quarterly report" --body "Attached."

Wie unterscheiden sich die Rate Limits der E-Mail-Provider?

Die Durchsetzung von Rate Limits variiert stark zwischen den 5 großen E-Mail-Providern. Gmail nutzt Quota-Einheiten mit Kosten pro Methode. Microsoft Graph zählt Requests flach. Yahoo und iCloud erzwingen undokumentierte Verbindungslimits auf IMAP-Ebene. Exchange EWS drosselt über gleichzeitige Requests. Die Tabelle unten zeigt die Zahlen, die für automatisierte E-Mail-Workflows am wichtigsten sind: Requests pro Sekunde, Nachrichten pro Tag und Obergrenzen für Anhänge.

Die Spalte "Effektive Reads/Sek." spiegelt den realistischen Durchsatz für ein list + get-Sync-Muster wider, nicht das theoretische Maximum aus der Provider-Dokumentation. Gmails Einheiten-System ist für leseintensive Workloads am großzügigsten. Graphs flaches Zählmodell ist einfacher, aber restriktiver für Bulk-Sync. Yahoo und iCloud veröffentlichen keine exakten Zahlen — die Schätzungen oben stammen aus empirischen Tests mit dem CLI über Konten unterschiedlichen Alters hinweg.

Welche SMTP-Fehlercodes signalisieren Rate Limiting?

Rate-Limit-Fehler im E-Mail-Umfeld fallen in zwei Kategorien: HTTP-Statuscodes von REST-APIs und SMTP Enhanced Status Codes von Mailservern. Die Antwort HTTP 429 "Too Many Requests" ist das Standardsignal der Gmail API und von Microsoft Graph. SMTP-Server verwenden die 4.7.x-Familie der Enhanced Status Codes. Welcher Code vorliegt, entscheidet, ob Sie sofort wiederholen können oder Stunden warten müssen.

Die Unterscheidung zwischen 4xx- und 5xx-Enhanced-Status-Codes ist wichtig. Ein 4.7.28 von Gmail ist temporär und löst sich von selbst. Ein 5.7.3 von Exchange bedeutet, dass Sie eine harte Tagesobergrenze erreicht haben. Laut Googles Dokumentation zu Workspace-Sendelimits sind kostenlose Gmail-Konten auf 500 Nachrichten pro Tag begrenzt, während Google-Workspace-Konten 2.000 erhalten. Das CLI parst diese Fehlercodes und passt sein Retry-Verhalten entsprechend an.

Wie sollten Retries nach einem Rate Limit aussehen?

Exponential Backoff mit Jitter ist die Standard-Retry-Strategie für E-Mail-API Rate Limits. Das Muster verdoppelt die Wartezeit nach jedem fehlgeschlagenen Versuch (1s, 2s, 4s, 8s) und addiert einen zufälligen Jitter von 0 bis 1 Sekunde, um Thundering-Herd-Probleme zu vermeiden, wenn mehrere Clients gleichzeitig dasselbe Limit treffen. Ohne Jitter stapeln sich synchronisierte Retries paralleler Worker und verlängern das Throttle-Fenster.

Laut Googles Dokumentation zur API-Fehlerbehandlung liegt die empfohlene maximale Retry-Anzahl bei 5 Versuchen mit einer Obergrenze von 32 Sekunden für das Backoff-Intervall. Microsofts Graph-Dokumentation empfiehlt, den Wert des Retry-After-Headers exakt zu übernehmen, statt eine eigene Verzögerung zu berechnen. In der Praxis liegt der Retry-After-Wert von Gmail typischerweise bei 1-60 Sekunden, während Graph je nach Schwere des Throttlings 5-300 Sekunden zurückgibt.

Wenn Sie die Gmail- oder Graph-API direkt aufrufen, müssen Sie diese Schleife selbst implementieren. Das Python-Snippet unten zeigt eine minimale Implementierung mit Jitter. Jeder Retry verdoppelt die Basisverzögerung und addiert bis zu 1 Sekunde zufälligen Jitter. Nach 5 Fehlschlägen wirft die Funktion eine Exception, statt endlos weiterzulaufen.

import time, random, requests

def call_with_backoff(url, headers, max_retries=5):
    delay = 1
    for attempt in range(max_retries):
        resp = requests.get(url, headers=headers)
        if resp.status_code != 429:
            return resp
        retry_after = int(resp.headers.get("Retry-After", delay))
        jitter = random.uniform(0, 1)
        wait = retry_after + jitter
        print(f"Rate limited. Retry {attempt + 1}/{max_retries} in {wait:.1f}s")
        time.sleep(wait)
        delay = min(delay * 2, 32)
    raise Exception("Max retries exceeded")

Wie behandelt das CLI Rate Limits intern?

Nylas CLI behandelt Rate Limits auf der Plattformebene, sodass Sie keine eigene Retry-Logik schreiben. Erhält die zugrunde liegende Nylas API ein 429 von Gmail, Graph oder einem anderen verbundenen Provider, wiederholt sie automatisch mit Exponential Backoff. Das CLI erbt dieses Verhalten. Ein einzelner nylas email list --limit 500-Befehl kann im Hintergrund Dutzende paginierte API-Aufrufe auslösen, und jeder einzelne respektiert die Throttle-Signale des Providers, ohne Fehler an Sie durchzureichen.

Die Plattform verarbeitet über 1,2 Milliarden API-Aufrufe pro Monat über Gmail, Outlook, Exchange, Yahoo, iCloud und IMAP-Provider hinweg. Bei diesem Volumen ist die Retry-Logik gegen jedes Rate-Limit-Muster aus der Tabelle oben getestet. Das hier beschriebene Provider-Verhalten basiert auf dokumentiertem Verhalten und unseren Tests mit Gmail und Outlook; prüfen Sie provider-spezifische Annahmen für Yahoo, iCloud oder EWS lokal, bevor Sie sie produktiv einsetzen.

Um die rohe API-Antwort inklusive Rate-Limit-Headern zu sehen, hängen Sie --json an einen beliebigen Befehl an. Die JSON-Ausgabe enthält Metadatenfelder, die die Response-Header des Providers sichtbar machen. Das hilft beim Debuggen von Skripten, die mehrere CLI-Befehle verketten, weil Sie nachvollziehen können, ob ein 429 auftrat und wie lange der Retry gewartet hat.

# Fetch 500 messages with full JSON output including response metadata
nylas email list --limit 500 --json | jq '.[0:3]'

Für Bulk-Operationen wie das Synchronisieren eines kompletten Postfachs oder den Versand einer Kampagne mit 2.000 Nachrichten reiht das CLI Requests intern in eine Queue ein und bleibt innerhalb der Provider-Limits. Ein vollständiger Gmail-Inbox-Sync von 10.000 Nachrichten dauert etwa 3 Minuten bei der Rate, die das Kontingent dauerhaft erlaubt — verglichen mit rund 40 Sekunden, wenn man die Limits komplett ignorieren könnte.

Welche Batch-Limits gelten pro Provider?

Batch-Operationen gruppieren mehrere API-Aufrufe in einem einzigen HTTP-Request, reduzieren den Roundtrip-Overhead und umgehen teilweise die Drosselung pro Request. Gmail unterstützt Batch-Requests mit bis zu 100 Aufrufen pro Batch, während Microsoft Graph Batches auf 20 Operationen begrenzt. Exchange EWS hat keinen formalen Batch-Endpunkt, unterstützt aber gruppierte Operationen über FindItem mit Paging.

Laut Googles Dokumentation zu Batch-Requests kostet jede einzelne Operation innerhalb eines Gmail-Batches weiterhin ihre vollen Quota-Einheiten. Ein Batch aus 100 messages.get-Aufrufen kostet 500 Einheiten — genauso viel wie 100 Einzelaufrufe. Der Vorteil liegt in der Latenz, nicht in der Quota-Ersparnis. Microsofts $batch-Endpunkt funktioniert anders: Der Batch selbst zählt als ein einziger Request gegen das 10.000/10-Min.-Throttling, aber jede Operation darin läuft unabhängig und kann einzeln fehlschlagen.

Das CLI nutzt Batching überall dort, wo der Provider es unterstützt. Für Gmail gruppiert es messages.get-Aufrufe in Batches zu 100, um die Latenz beim Paginieren zu reduzieren. Für Graph packt es bis zu 20 Operationen in einen $batch-Request, um den Throttle-Vorteil zu maximieren. Sie müssen nichts konfigurieren; das passiert automatisch hinter nylas email list.

Wie überwachen Sie Ihre Rate-Limit-Auslastung?

Gmail zeigt die Quota-Auslastung in der Google Cloud Console unter APIs & Services > Gmail API > Quotas, aufgeschlüsselt nach Methode und in Echtzeit. Microsoft Graph stellt Nutzungsdaten im Azure-Portal unter App Registrations > Ihre App > Performance bereit. Beide Dashboards aktualisieren sich alle 5 Minuten und zeigen 30 Tage Historie — genug, um Muster in Throttle-Ereignissen zu erkennen.

Für CLI-basierte Workflows hängen Sie --json an einen beliebigen Befehl an und leiten die Ausgabe durch jq, um Ergebnisse zu zählen und das API-Aufrufvolumen abzuschätzen. Der Befehl unten listet 100 Nachrichten, zählt sie und berechnet die ungefähr verbrauchten Gmail-Quota-Einheiten. Bei 5 Einheiten pro messages.list-Seite (100 Ergebnisse pro Seite) plus 5 Einheiten pro messages.get für jede Nachricht kosten 100 Nachrichten rund 505 Quota-Einheiten.

# Count messages returned and estimate Gmail quota cost
COUNT=$(nylas email list --limit 100 --json | jq 'length')
echo "$COUNT messages fetched"
echo "Estimated quota cost: $((5 + COUNT * 5)) units"

Wenn Sie periodische Sync-Skripte betreiben, loggen Sie nach jedem Lauf Anzahl und Zeitstempel. Ein Cronjob, der alle 5 Minuten synchronisiert und 200 Nachrichten pro Lauf abruft, verbraucht etwa 1.005 Einheiten pro Zyklus, also rund 289.440 Einheiten pro Tag. Das liegt klar innerhalb des täglichen Projektlimits von 1 Milliarde Einheiten, lohnt sich aber zu beobachten, wenn Sie auf Tausende Nutzer skalieren.

Nächste Schritte

• Vollständige Befehlsreferenz durchsuchen — jeder E-Mail-, Kalender- und Kontakte-Befehl im Überblick
• Gmail-API-Pagination und -Sync erklärt für einen Deep Dive zu nextPageToken und historyId
• E-Mail vom Terminal senden für den Schnellstart mit nylas email send
• Beste E-Mail-Infrastruktur für AI-Agents zum Vergleich von API-Plattformen für automatisierte E-Mail-Workflows