Zum Hauptinhalt springen
Die Data API erzwingt ein Rate-Limit von 2.500 Requests pro Stunde pro API-Key. Alle /v1/-Endpunkte teilen sich dieses eine Budget: Kategorie-Endpunkte, /v1/raw, /v1/catalog und /v1/changes ziehen vom selben Zähler ab. Jeder Request mit gültigem Key zählt genau einmal, einschließlich Wiederholungen, Polling-Aufrufen, 304 Not Modified-Antworten und Client-Fehlern wie 400, 403, 404 oder 422. 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. Jeder API-Key hat sein eigenes Budget. Erreicht ein Key das Limit, ist ein zweiter Key desselben Kunden nicht betroffen.

​
Requests ohne gültigen Key

Requests ohne X-API-Key-Header oder mit unbekanntem, deaktiviertem oder abgelaufenem Key zählen auf kein Budget. Die API beantwortet sie mit 401 bzw. 403, nie mit 429.

​
Beispiel einer 429-Antwort

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

​
Umgang mit Rate-Limits

Erfolgreiche Antworten (2xx, 304) und 429-Antworten enthalten drei Header, mit denen du proaktiv drosseln kannst, statt auf einen 429 zu warten:
  • X-RateLimit-Limit — im Fenster erlaubte Requests (2500)
  • X-RateLimit-Remaining — im aktuellen Fenster verbleibende Requests, über alle Endpunkte
  • X-RateLimit-Reset — Unix-Zeitstempel in Sekunden, zu dem das Fenster zurückgesetzt wird
Andere Fehlerantworten mit gültigem Key (400, 403, 404, 422) tragen diese Header nicht, zählen aber trotzdem. Die nächste erfolgreiche Antwort zeigt den aktuellen Stand. 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 2 Sekunden einen Request stellt, bleibt sicher unter dem Limit von 2.500 Requests.
Nutze den Delta-Sync-Endpunkt (GET /v1/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.