API Rate Limiting
Definition: API Rate Limiting bezeichnet die technische Begrenzung der Anzahl an Anfragen (Requests), die ein Client innerhalb eines definierten Zeitraums an eine API senden darf. Wird das Limit überschritten, antworten APIs mit dem HTTP-Statuscode 429 «Too Many Requests» und optional einem Retry-After-Header der angibt wann der nächste Request erlaubt ist. Rate Limiting schützt API-Server vor Überlastung und Denial-of-Service-Angriffen, verhindert Missbrauch einzelner Nutzer und stellt sicher, dass alle API-Konsumenten faire und stabile Zugangsbedingungen erhalten.
Erläuterung
Im Online-Marketing-Kontext ist Rate Limiting besonders relevant bei der Nutzung von Marketing-APIs: Google Ads, Meta Marketing API, Google Search Console, SEO-Tools (Ahrefs, SEMrush) und CRM-Systeme setzen strikte Limits. Marketing-Automatisierungen die diese Limits ignorieren, erzeugen Fehler, unvollständige Datensynchronisierungen und instabile Kampagnen-Updates. Ein robustes Handling von Rate-Limit-Fehlern ist daher ein Qualitätsmerkmal jeder professionellen Marketing-Integration.
Rate-Limiting-Algorithmen
- Fixed Window: Limit gilt für festes Zeitfenster (z. B. 1.000 Requests pro Stunde von 0–60 min); einfach zu implementieren; Nachteil: Burst-Möglichkeit am Fensterende und -anfang (1.000 Requests in letzter Minute + 1.000 in erster Minute des neuen Fensters = 2.000 in kurzer Zeitspanne)
- Sliding Window: Betrachtet Requests der letzten X Sekunden/Minuten rollierend; gleichmäßigere Last als Fixed Window; verhindert Burst-Missbrauch; komplexer zu implementieren; von vielen modernen APIs bevorzugt
- Token Bucket: «Eimer» wird mit Tokens mit fester Rate gefüllt (z. B. 10 Tokens/Sekunde); jeder Request verbraucht Token; ermöglicht kurze Bursts (wenn Eimer voll); sehr verbreitet (AWS, Stripe, Twilio nutzen Varianten); flexibel für unterschiedliche Request-Gewichte
- Leaky Bucket: Requests werden in Warteschlange gestellt und mit konstanter Rate abgearbeitet; gleichmäßigste Last; eignet sich für Systeme mit strikten Durchsatzanforderungen; weniger burst-tolerant als Token Bucket
HTTP-Header und Fehlercodes
- Standard-Rate-Limit-Header: X-RateLimit-Limit: maximale Requests im Zeitfenster; X-RateLimit-Remaining: verbleibende Requests; X-RateLimit-Reset: Zeitstempel wann Limit zurückgesetzt wird; Retry-After: Sekunden bis nächster erlaubter Request (im 429-Response)
- HTTP 429 Too Many Requests: Standardisierter Statuscode für Rate-Limit-Überschreitung (RFC 6585); enthält typisch Retry-After-Header; von HTTP 503 Service Unavailable unterscheiden (503 = Server-Problem, nicht Client-Problem)
- HTTP 403 vs. 429: Manche APIs geben 403 Forbidden bei Rate-Limit-Überschreitung statt 429; Dokumentation des jeweiligen API-Anbieters prüfen; eigene Fehlerbehandlung muss beide Fälle abdecken
Wichtige Marketing-API-Limits
- Google Ads API: Standard-Quota: 15.000 Operationen pro Tag; erhöhbare Limits über Google-Antrag; Bulk-Operationen (mutateAdGroups etc.) zählen als einzelne Operationen unabhängig von der Anzahl der enthaltenen Objekte; höhere Limits für Agenturen via Manager-Account
- Meta Marketing API: Verschiedene Tiers je nach App-Status; Rate Limits basieren auf App-ID und Ad-Account-ID; Business Use Case Rate Limit: Standard 200 calls/hour je Ad Account; Throttling über x-business-use-case-usage-Header; Batch Requests reduzieren API-Calls
- Google Search Console API: 1.200 Requests pro Minute per User; Quota erhöhbar über Google Cloud Console; 1.000 Zeilen pro Request für Suchanfragen-Daten; Paginierung für größere Datasets notwendig
- SEO-Tool-APIs: Ahrefs: Credits-basiert (je nach Subscription); SEMrush: Einheiten pro Monat; beide deutlich restriktiver als Google-APIs; Cache API-Responses um wiederholte identische Anfragen zu vermeiden
Fehlerbehandlung und Best Practices
- Exponential Backoff: Nach 429-Fehler warten und Anfrage erneut versuchen; Wartezeit verdoppeln bei jedem weiteren Fehler (1s → 2s → 4s → 8s); Jitter (zufällige Variation) hinzufügen um synchrone Retry-Stürme zu verhindern; maximale Wartezeit cap (z. B. 60 Sekunden) definieren
- Proaktives Rate-Limit-Monitoring: X-RateLimit-Remaining in Response-Headern beobachten; Requests verlangsamen bevor Limit erreicht wird statt danach; Alert einrichten wenn Remaining unter 10–20 % fällt
- Request-Batching: Mehrere Operationen in einen API-Call bündeln wenn API Batch-Endpoints unterstützt; Google Ads API: batch mutate; Meta API: Batch Requests; reduziert Gesamtzahl der API-Calls signifikant
- Response-Caching: Wiederholte identische API-Calls cachen (Redis, Memcached); Cache-Invalidierung bei Datenänderungen; besonders bei Read-APIs (Reporting, Analytics) sehr effektiv; kann API-Calls um 50–80 % reduzieren
Praxistipp: Implementieren Sie in jeder Marketing-API-Integration drei Schutzmechanismen: (1) Exponential Backoff mit Jitter für alle 429-Fehler (nicht nur einmal retry, sondern mit steigenden Wartezeiten bis zu einem Maximum von 60 Sekunden); (2) Rate-Limit-Header auslesen und proaktiv verlangsamen wenn X-RateLimit-Remaining unter 20 % fällt; (3) Read-API-Responses in Redis oder Memcached mit TTL von 5–60 Minuten cachen (je nach Datenfreshenanforderung). Diese drei Maßnahmen machen Ihre Marketing-Automatisierung stabil gegenüber Rate-Limit-Schwankungen ohne aufwändige Infrastruktur-Änderungen.