Skip to main content
Die /v1-API erzwingt zwei voneinander unabhängige Anfragekontingente. Eine Anfrage wird abgelehnt, wenn eines der beiden Kontingente erschöpft ist. Das Kontingent pro Schlüssel folgt dem Schlüssel überallhin, wo er verwendet wird. Das Kontingent pro IP-Adresse ist das einzige Kontingent für nicht authentifizierten Datenverkehr und eine zweite Obergrenze für authentifizierten Datenverkehr.
Die Begrenzungen werden vor der Authentifizierung durchgesetzt, sodass auch Anfragen mit ungültigen oder fehlenden Anmeldedaten auf das Kontingent der Quelle angerechnet werden. Die genauen numerischen Kontingente werden vom Betreiber konfiguriert und können sich ändern; der unten beschriebene Antwortvertrag ist die stabile Schnittstelle, auf der Sie aufbauen sollten.
Authentifizieren Sie sich mit einer der beiden Basic-Anmeldedatenvarianten – siehe Quickstart (apikey:secret oder secret:). Setzen Sie BASE auf den regionalen Host der Organisation – siehe Regionen.

Die 429-Antwort

Wenn ein Kontingent erschöpft ist, gibt die API 429 Too Many Requests mit einem Retry-After-Header (in Sekunden) und dem standardmäßigen Problem-Details-Body zurück:
429 Too Many Requests
Die Antwort gibt nicht an, welches Kontingent erschöpft wurde. Behandeln Sie jede 429 gleich: warten und dann erneut versuchen.

429-Antworten behandeln

1

Retry-After beachten

Warten Sie mindestens so viele Sekunden, wie im Retry-After-Header angegeben sind, bevor Sie es erneut versuchen. Ein früherer erneuter Versuch verbraucht nur erneut Kontingent für Anfragen, die abgelehnt werden.
2

Bei wiederholten Fehlern exponentiell zurückweichen

Wird ein erneuter Versuch wieder abgelehnt, verlängern Sie Ihre Wartezeit (Backoff) und fügen Sie zufälligen Jitter hinzu, damit parallele Worker nicht im Gleichschritt erneut senden. Kürzen Sie niemals den Retry-After des Servers, um ihn an eine lokale Obergrenze anzupassen. Wenn der Server Sie auffordert, länger zu warten, als Ihr Kontingent für erneute Versuche erlaubt, brechen Sie ab und planen Sie die Aufgabe für einen späteren Zeitpunkt ein.
3

Anfragerate glätten

Bevorzugen Sie eine gleichmäßige Anfragerate gegenüber Lastspitzen. Verwenden Sie bei Massenabfragen die maximale Seitengröße (limit=500), um die Sammlung mit weniger Anfragen abzudecken – siehe Paginierung. Wenn mehrere Listenabfragen parallel laufen (zum Beispiel Power-BI-Tabellen), halten Sie die Parallelität moderat und beachten Sie Retry-After, damit eine vorübergehende 429-Antwort nicht die gesamte Aktualisierung scheitern lässt.
Dieses Beispiel wiederholt nur 429-Antworten bei einer GET-Anfrage, mit höchstens fünf Versuchen und höchstens 60 Sekunden Wartezeit zwischen den Versuchen. Bei anderen Fehlern bricht es sofort ab. Netzwerk-Timeouts werden an den Aufrufer weitergegeben. Konfigurieren Sie Timeouts und Kontingente für erneute Versuche passend zu Ihrer Arbeitslast. requests interpretiert das Lese-Timeout als maximale Leerlaufzeit beim Empfang von Daten, nicht als Gesamtfrist. Laden Sie LIVING_SECURITY_API_KEY aus Ihrem Secret Manager. Installieren Sie requests, bevor Sie dieses Beispiel ausführen. Rufen Sie get_with_retry("/organization") auf, um es zu verwenden.
Python
Kopieren Sie diese Schleife nicht um einen Schreibvorgang herum. Ein Timeout nach einem Schreibvorgang kann bedeuten, dass der Server ihn festgeschrieben hat, bevor die Verbindung fehlschlug. Wiederholen Sie einen Schreibvorgang nur dann, wenn die Referenz dieses Vorgangs ausdrücklich Idempotenz dokumentiert, und verwenden Sie denselben Schlüssel und dieselbe Nutzlast. Gleichen Sie andernfalls den Zustand der Ressource ab, bevor Sie es erneut versuchen.

Empfohlener Aktualisierungsplan

Dimensionieren Sie die Aktualisierungshäufigkeit anhand Ihres Schlüsselkontingents und der Seitengröße. Ein vollständiger historischer Ladevorgang einer großen Sammlung ist ein einmaliger Aufwand; bevorzugen Sie für regelmäßige Aktualisierungen im laufenden Betrieb inkrementelle Zeitfenster, damit jeder Lauf deutlich unter dem Kontingent bleibt. Legen Sie limit=500 immer explizit fest – der Standardwert von 25 vervielfacht die Anzahl der Anfragen.