---
title: Rate-Limits
description: Vertragsspezifische Rate-Limits, der Retry-After-Header und Muster zur Einhaltung des Budgets.
canonical: https://developer.unico.io/de/dual-api/developers/api-reference/rate-limits
locale: de
generated_by: markdown-export
---

- [/de/](/de/)
- [API-Referenz](/de/dual-api/developers/api-reference/)
- Rate-Limits

**Auf dieser Seite# 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-TeamGenaue 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](/de/developers/webhooks-and-events) 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 RequestsRetry-After: 12
```

HeaderBedeutung`Retry-After`Anzahl 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.
### Magic Link Webhook-Zustellung​

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​

[Authentifizierung](/de/dual-api/developers/api-reference/authentication) — Token-Caching-Strategie.
[Webhooks und Ereignisse](/de/developers/webhooks-and-events) — Polling durch Push ersetzen.
[Fehlercodes > Wiederholungsrichtlinie](/de/dual-api/developers/api-reference/error-codes#retry-policy) — wann (und wann nicht) zu wiederholen.
Zuletzt aktualisiert am 8. Okt. 2026**