Zum Hauptinhalt springen

Rate-Limits

Ein Rate-Limit definiert die maximale Anzahl von Anfragen, die eine Anwendung innerhalb eines bestimmten Zeitraums an die API stellen kann. Dieser Mechanismus ist entscheidend, um die allgemeine Gesundheit und Zuverlässigkeit der Dienste aufrechtzuerhalten.

Warum wir Rate-Limiting verwenden​

API-Stabilität und -Leistung
  • Verhindert, dass ein einzelner Client Server mit übermäßigen Anfragen überlastet.
  • Gewährleistet konsistente und vorhersehbare Antwortzeiten für alle Clients.
  • Schützt Backend-Dienste vor unerwarteten Traffic-Spitzen.
  • Erhält ein stabiles und kontrolliertes Lastmuster in der Infrastruktur.
Sicherheit
  • Stärkt die Abwehr gegen Angriffe wie Brute-Force.
  • Mindert das Risiko von Distributed Denial-of-Service (DDoS).
  • Reduziert die Auswirkungen schlecht implementierter Integrationen.
  • Begrenzt potenzielle Schäden durch kompromittierte API-Anmeldedaten.
Ressourcenzuteilung
  • Gewährleistet ausgewogenen Zugang zu API-Ressourcen für alle Clients.
  • Verhindert, dass missbräuchliche Nutzung durch einige die Erfahrung anderer Benutzer beeinträchtigt.
  • Ermöglicht die Priorisierung von Traffic nach Geschäftskriterien und -bedürfnissen.
  • Fördert eine effizientere und nachhaltigere API-Nutzungspraxis.

Wie Rate-Limiting funktioniert​

Jeder API-Aufruf zählt zum erlaubten Anfragen-pro-Sekunde-Limit. Der Standardwert beträgt 10 RPS pro Mandant. Wenn das Limit überschritten wird, gibt die API HTTP 429 Too Many Requests zurück.

Bestätigen Sie dies mit Ihrem Onboarding-Team

Genaue Limits werden pro Mandant konfiguriert. Wenden Sie sich vor der Dimensionierung für Hochdurchsatz-Integrationen an Ihr Onboarding-Team, um die für Ihr Konto geltenden Limits zu bestätigen.

Umgang mit 429-Fehlern​

Eine Rate-Limit-Erhöhung beantragen

Wenn Ihre Operation ein erhöhtes Anfragevolumen haben wird (vorübergehend oder dauerhaft), benachrichtigen Sie das Unico-Team, um das Rate-Limit für Ihre Umgebung zu erhöhen. Diese Anfrage sollte vor dem tatsächlichen Anstieg des Volumens gestellt werden, um zu verhindern, dass Ihre Anwendung außer Betrieb geht.

Anwendungsverhalten überprüfen
  • Prüfen Sie Ihren Code, um ineffiziente API-Nutzungsmuster zu identifizieren.
  • Suchen Sie nach unbeabsichtigten Schleifen oder redundanten API-Aufrufen.
  • Verteilen Sie Anfragen gleichmäßiger über die Zeit, anstatt sie in großen Bursts zu senden.
Caching implementieren
  • Cachen Sie häufig abgerufene Daten, die sich selten ändern.
  • Verwenden Sie das OAuth2-Zugriffstoken für seine volle 1-Stunden-TTL — rufen Sie nicht POST /oauth2/token pro Anfrage auf.
  • Implementieren Sie geeignete Cache-Invalidierungsstrategien.
Webhooks anstelle von Polling verwenden

Abonnieren Sie Webhooks und Ereignisse für PROCESS_STATE_FINISHED anstatt GET /client/v1/process/\{id\} zu pollen. Eine Polling-Schleife kann bei starkem Traffic das GET-Prozess-Budget schnell ausschöpfen.

Was passiert, wenn Sie das Limit überschreiten​

Die Plattform gibt zurück:

HTTP/1.1 429 Too Many Requests
Retry-After: 12
HeaderBedeutung
Retry-AfterAnzahl der Sekunden, die vor dem erneuten Versuch gewartet werden muss. Halten Sie sich daran.

Falls Retry-After fehlt, verwenden Sie exponentiellen Backoff (1s, 2s, 4s, 8s, …) mit maximal 60s.

Überlegungen zur Gleichzeitigkeit​

Rate-Limits begrenzen Anfragen pro Minute, aber die Plattform hat auch Gleichzeitigkeitsgrenzen auf Infrastrukturebene. Auch wenn Sie Budget für 100 Anfragen/Minute haben, ist es wahrscheinlicher, dass alle 100 in der gleichen Sekunde abgelehnt werden, als wenn sie über die Minute verteilt werden.

Streben Sie bei Hochdurchsatz-Integrationen einen gleichmäßigen RPS anstelle von Bursts an.

Trully hat eigene Lieferkontingente für Webhook V2. Der Webhook-Server muss innerhalb von 1 Minute antworten; langsamere Antworten werden verworfen (der Prozess des Benutzers ist nicht betroffen). Für eine konsistente Verarbeitung bestätigen Sie den Webhook schnell und verarbeiten Sie ihn asynchron.

Nächste Schritte​

Zuletzt aktualisiert am