Skip to main content
Die Trassets Data API erzwingt ein Rate-Limit von 500 Requests pro Stunde pro API-Key. Jeder Request zählt auf dieses Limit, einschließlich Wiederholungen und Polling-Aufrufen. Wenn du das Limit überschreitest, liefert die API einen 429-Statuscode, und du musst warten, bis das aktuelle Stundenfenster zurückgesetzt wird, bevor du weitere Requests stellen kannst.

​
Beispiel einer 429-Antwort

Wenn du das Rate-Limit erreichst, antwortet die API mit einem RFC-7807-Problem-JSON-Body:

​
Umgang mit Rate-Limits

Jede Antwort enthält die Header X-RateLimit-Limit und X-RateLimit-Remaining, mit denen du proaktiv drosseln kannst, statt auf einen 429 zu warten. Wenn du dennoch eine 429-Antwort erhältst, nutze den Retry-After-Header, statt eine Wartezeit zu schätzen:
  1. Stoppe sofort das Senden neuer Requests.
  2. Lies den Retry-After-Header — er gibt die genaue Anzahl Sekunden bis zum Zurücksetzen des aktuellen Fensters an. Warte mindestens so lange, bevor du es erneut versuchst.
  3. Verdopple die Wartezeit bei jedem weiteren Versuch, falls der 429-Fehler weiterhin auftritt.
  4. Nimm den normalen Request-Abstand wieder auf, sobald Requests wieder erfolgreich sind.
Bei lang laufenden Sync-Jobs verteile die Requests gleichmäßig über die Stunde, statt sie am Anfang zu bündeln. Ein Job, der beispielsweise alle 7 Sekunden einen Request stellt, bleibt sicher unter dem Limit von 500 Requests.
Nutze den Delta-Sync-Endpunkt (GET /changes), um auf geänderte Tabellen zu pollen, statt wiederholt jeden Endpunkt abzufragen. So kannst du Endpunkte überspringen, die sich seit deinem letzten Sync nicht geändert haben, und reduzierst dein gesamtes Request-Volumen.