Anfragelimits
Anfragelimits je Tarif für Listings und Social, das Format der 429-Antwort und das Vorgehen bei Wartezeiten und Wiederholungsversuchen.
Die Listings API zählt Anfragen pro Konto und gleicht sie mit dem Anfragelimit Ihres Tarifs ab. Wenn Sie das Limit einhalten, bleibt Ihre Integration reaktionsfähig; bei einer Überschreitung wird 429 Too Many Requests mit allen Informationen zurückgegeben, die Sie für einen geregelten Wiederholungsversuch benötigen.
Limits je Tarif
Sie testen die API ohne kostenpflichtigen Tarif? Der kostenlose Sandbox-Tagespass liefert Ihnen beim Start des Tagespasses zusammen mit dem API-Schlüssel die aktuell geltenden Anfragelimits.
Die Limits hängen vom Tarif ab und gelten pro Konto: Jeder API-Schlüssel eines Kontos nutzt dasselbe Kontingent. Anfragen werden in drei Zeitfenstern gezählt: mit einem Limit für Anfragespitzen pro Minute, einem stündlichen Limit und einer täglichen Obergrenze. Jede Anfrage wird unabhängig vom Endpunkt gleich gewichtet. Eine kostenlose Testphase läuft mit dem von Ihnen gewählten Tarif, sodass dessen Limits ab der ersten Anfrage gelten.
Social nutzt dasselbe Kontingent
Anfragen an Social-Endpunkte werden auf dasselbe Anfragekontingent pro Konto angerechnet wie alle anderen Anfragen. Ein POST /social/bulk-posts mit 500 Zeilen zählt als eine Anfrage, nicht als 500, sodass die gebündelte Übertragung die kostengünstigste Möglichkeit ist, viele Inhalte zu laden.
Listings und Social sind separate Abonnements, haben aber keine separaten Kontingente. Für ein Konto mit beiden Abonnements gelten die Limits der höheren der beiden Tarifstufen einmal gemeinsam für alle Endpunkte — weder werden die Limits addiert, noch gibt es ein eigenes Kontingent pro Produkt. Für Kunden mit Listings Launch und Social Growth gelten die oben aufgeführten Growth-Werte für ihren gesamten Anfrageverkehr.
Die 429-Antwort
Wenn Sie ein Limit überschreiten, gibt die API HTTP 429 und die standardmäßige Fehlerantwort zurück. Drei Felder sind für Wiederholungsversuche relevant:
retry_after_seconds: wie lange Sie vor einem erneuten Versuch warten müssen. Der HTTP-HeaderRetry-Afterenthält denselben Wert, sofern er vorhanden ist.correlation_id: eine Anfragekennung, die Sie bei einer Kontaktaufnahme mit dem Support angeben sollten.doc_url: ein Link zum Eintragrate_limitedin der Fehlercode-Referenz.
{ "error": { "code": "RATE_LIMITED", "message": "Too many requests. Slow down.", "retry_after_seconds": 30, "correlation_id": "9f2c1e64-2b1a-4b0e-9f1a-2c7d5e8a1b3c", "doc_url": "https://listingsapi.com/docs/error-codes#rate_limited" }}429-Antworten mit zunehmenden Wartezeiten behandeln
Beachten Sie retry_after_seconds, sofern vorhanden, und erhöhen Sie andernfalls die Wartezeit exponentiell: Verdoppeln Sie die Verzögerung bei jedem aufeinanderfolgenden 429 bis zu einer Obergrenze und fügen Sie eine kleine zufällige Abweichung hinzu, damit eine Gruppe von Clients ihre Anfragen nicht gleichzeitig wiederholt.
import randomimport time import requests MAX_RETRIES = 5 def get_with_backoff(url: str, headers: dict, max_retries: int = MAX_RETRIES): for attempt in range(max_retries): resp = requests.get(url, headers=headers) if resp.status_code != 429: resp.raise_for_status() return resp.json() # Prefer the server's hint; fall back to exponential backoff + jitter. body = resp.json().get("error", {}) retry_after = body.get("retry_after_seconds") if retry_after is None: retry_after = min(2 ** attempt, 30) + random.uniform(0, 1) time.sleep(retry_after) raise RuntimeError("Still rate limited after retrying")Unter dem Limit bleiben
- Fordern Sie jeweils nur eine Seite an: Eng getaktete parallele Paginierungsschleifen sind die häufigste Ursache für
429-Antworten. Lesen SiepageInfo.hasNextPageund rufen Sie die nächste Seite erst ab, nachdem die aktuelle Seite zurückgegeben wurde. - Filtern Sie serverseitig mit dem Abfrageparameter
filter, statt jede Seite abzurufen und Zeilen clientseitig zu verwerfen. - Speichern Sie Antworten, die sich selten ändern, im Cache, statt sie bei jeder Anfrage erneut abzurufen.