Limits und Parallelität

Aktuelle Standardwerte sind 180 Anfragen/Minute pro IP, 60 pro Schlüssel und 90 pro Konto. Das IP-Limit gilt auch für authentifizierte Anfragen; mehrere Schlüssel teilen das Kontolimit. Pro Konto laufen höchstens 5 Datenanfragen gleichzeitig; zusätzlich gilt max_concurrent_requests des Schlüssels. Request-Bodies sind auf 256 KB und Seiten auf 50 Einträge begrenzt.

Das Tageskontingent begrenzt erfolgreiche REST-Datenaufrufe pro Tag, die Rate begrenzt Anfragen pro Minute und Parallelität begrenzt noch laufende Anfragen. Die Schlüsselprüfung verbraucht keinen Tagesaufruf, unterliegt aber der Rate. Ein kleineres limit oder ein neuer Schlüssel umgeht das Tageskontingent nicht. Serielle Anfragen senken Parallelität, erhöhen aber das Tageskontingent nicht.

Nach 10 REST-Datenaufrufen folgt HTTP 429 mit API_DAILY_LIMIT_REACHED. Warte bis 00:00 Asia/Shanghai. Neue oder rotierte Schlüssel setzen das Kontolimit nicht zurück.

Beachte bei RATE_LIMITED Retry-After und nutze Backoff. Gültige Schlüssel, Berechtigungen, Raten-, Parallelitäts- und Kontobeschränkungen bleiben erforderlich.

Wähle die Behandlung anhand von error.code, nicht nur anhand von HTTP 429. RateLimit-Limit, RateLimit-Remaining und RateLimit-Reset beschreiben das kurze Ratenfenster. Reset ist ein Unix-Zeitstempel in Sekunden, kein Tagesreset. Bei erschöpfter Rate gibt Retry-After Sekunden an; bei Parallelitäts- oder Tageslimits kann der Header fehlen. Lies daily_usage für die Tagesnutzung und error.details.daily_usage beim Tageslimitfehler.

Jede erfolgreiche REST-Datenanfrage zählt einmal, auch leere Ergebnisse und Cache-Treffer. Derselbe Idempotency-Key mit denselben Parametern liefert die ursprüngliche Antwort ohne weiteren Tagesaufruf. Fehlgeschlagene Anfragen und 304-Antworten verbrauchen kein Tageskontingent.

Beachte bei RATE_LIMITED Retry-After und nutze Backoff. Gültige Schlüssel, Berechtigungen, Raten-, Parallelitäts- und Kontobeschränkungen bleiben erforderlich.

Warte bei RATE_LIMITED zuerst gemäß Retry-After. Fehlt der Header, reduziere Parallelität und nutze begrenztes exponentielles Backoff mit kleiner Zufallsverzögerung, etwa 1, 2 und 4 Sekunden, bevor du stoppst und die Anfrage-ID protokollierst. Wiederhole API_DAILY_LIMIT_REACHED nicht sekündlich, sondern warte auf den Tagesreset. Behebe bei 401, 403 oder ungültigen Parametern zuerst die Ursache.

Behalte Idempotency-Key und Parameter beim Wiederholen derselben REST-Datenoperation bei. Erzeuge für eine neue logische Operation einen neuen Wert; geänderte Parameter mit demselben Key verursachen IDEMPOTENCY_CONFLICT. Unterschiedliche Seiten sind unterschiedliche Operationen. Auch wiederholbare 5xx-Antworten benötigen begrenztes Backoff.

Wenn zwei Schlüssel eines Kontos jeweils 5 Datenaufrufe abschließen, sind die gemeinsamen 10 REST-Tagesaufrufe aufgebraucht, selbst ohne Anfrage in der letzten Minute. Die Website hat ein separates Kontingent von 10 Suchen. MCP nutzt keines dieser Tageskontingente, kann bei zu vielen gleichzeitigen Anfragen aber weiterhin RATE_LIMITED auslösen.