Ratenlimits
Verstehe die getrennten Kontingente für Linkerstellung und Suche.
Jedes Konto kann innerhalb eines Fensters von 60 Sekunden 30 Aufrufe zur Linkerstellung ausführen, gemeinsam für REST POST /api/v1/links, POST /api/v1/uploads, POST /api/v1/sheets und MCP create_links. Eine direkte Anfrage und eine Stapelübermittlung verbrauchen jeweils einen Aufruf, unabhängig von der Anzahl der Eingaben. Jede Uploadreservierung und Tabellenübermittlung verbraucht einen Aufruf; untergeordnete Linkumwandlungen verbrauchen keinen.
Zugelassene Erstellungsanfragen und Ablehnungen wegen des Ratenlimits enthalten strukturierte Header:
RateLimit-Policy: "create-links";q=30;w=60
RateLimit: "create-links";r=29;t=60q ist das Kontingent und w dessen Zeitfenster in Sekunden. r sind die verbleibenden Aufrufe; t sind die Sekunden, bis ein Platz frei wird. Dies sind strukturierte Felder, keine bloßen Zahlen.
Ein ausgeschöpftes Kontingent ergibt 429 mit dem Problem rate-limited und Retry-After in Sekunden. Warte vor einem erneuten Versuch und stimme Aufrufer desselben Kontos aufeinander ab. Auftragsabfragen verbrauchen dieses Kontingent nicht; beachte deren Hinweise zu poll_after_seconds und Retry-After.
Suchfenster
Stichwortsuchen haben ein eigenes Kontingent von 30 Aufrufen pro Konto je 60 Sekunden. Die Suchzulassung verbraucht keine Linkerstellungsaufrufe. Aufgelöste Produkt-, Anbieter-, Tabellen- und nicht unterstützte Links überspringen die Stichwortsuche und verbrauchen keines der beiden Kontingente; unlesbare Links können zur Stichwortsuche führen.
Erfolgreiche Antworten nach der Zulassungsprüfung zur Stichwortsuche und Ablehnungen wegen des Suchlimits enthalten:
RateLimit-Policy: "search";q=30;w=60
RateLimit: "search";r=29;t=60Abgelehnte Suchen ergeben 429 mit search-rate-limited und Retry-After. Die Header-Felder bedeuten dasselbe wie oben. Die Antwortwiederholung über Idempotency-Key verbraucht keinen neuen Linkerstellungsaufruf; ein 429 wird nicht zur Wiederholung gespeichert.