Skip to main content
De /v1 API hanteert twee onafhankelijke aanvraagbudgetten. Een aanvraag wordt geweigerd als een van beide budgetten is uitgeput. Het budget per sleutel volgt de sleutel overal waar deze wordt gebruikt. Het budget per IP is het enige budget voor niet-geauthenticeerd verkeer en een tweede limiet voor geauthenticeerd verkeer.
Limieten worden afgedwongen vóór de authenticatie, waardoor aanvragen met ongeldige of ontbrekende inloggegevens ook meetellen voor het budget van de bron. De exacte numerieke budgetten worden door de operator geconfigureerd en kunnen wijzigen; het onderstaande responscontract is de stabiele interface waarop u kunt bouwen.
Authenticeer met een van beide Basic-credentialvormen; zie de Quickstart (apikey:secret of secret:). Stel BASE in op de regionale host van de organisatie; zie Regio’s.

De 429-respons

Wanneer een budget is uitgeput, retourneert de API 429 Too Many Requests met een Retry-After-header (in seconden) en de standaard problem-details-body:
429 Too Many Requests
De respons geeft niet aan welk budget is uitgeput. Behandel elke 429 op dezelfde manier: wacht en probeer het daarna opnieuw.

429-responses afhandelen

1

Houd rekening met Retry-After

Wacht minimaal het aantal seconden dat in de Retry-After-header staat voordat u het opnieuw probeert. Als u eerder opnieuw probeert, verbruikt u alleen opnieuw budget voor aanvragen die toch worden geweigerd.
2

Verleng de wachttijd exponentieel bij herhaling

Als een nieuwe poging opnieuw wordt geweigerd, verhoogt u uw backoff en voegt u willekeurige jitter toe, zodat parallelle workers niet synchroon opnieuw proberen. Verkort nooit de Retry-After van de server om binnen een lokale limiet te passen. Als de server u vraagt langer te wachten dan uw retrybudget toestaat, stopt u en plant u het werk voor later.
3

Spreid uw aanvraagfrequentie

Geef de voorkeur aan een constante aanvraagfrequentie boven pieken. Gebruik voor bulkleesacties de maximale paginagrootte (limit=500) om de collectie met minder aanvragen te doorlopen; zie paginering. Wanneer meerdere lijstdoorlopen parallel worden uitgevoerd (bijvoorbeeld Power BI-tabellen), houd de gelijktijdigheid dan bescheiden en houd rekening met Retry-After, zodat een tijdelijke 429 niet de hele verversing laat mislukken.
Dit voorbeeld probeert alleen 429-responses opnieuw voor een GET-aanvraag, met maximaal vijf pogingen en maximaal 60 seconden wachttijd tussen de pogingen. Bij andere fouten stopt het direct. Netwerktimeouts worden doorgegeven aan de aanroeper. Configureer timeouts en retrybudgetten naar uw workload. requests interpreteert de leestimeout als de maximale inactieve tijd tijdens het ontvangen van gegevens, niet als een algemene deadline. Laad LIVING_SECURITY_API_KEY uit uw secretmanager. Installeer requests voordat u dit voorbeeld uitvoert. Roep get_with_retry("/organization") aan om het te gebruiken.
Python
Kopieer deze lus niet rond een schrijfbewerking. Een timeout na een schrijfactie kan betekenen dat de server deze heeft doorgevoerd voordat de verbinding verbrak. Herhaal een schrijfbewerking alleen als de referentie van die bewerking idempotentie expliciet documenteert, en behoud dezelfde sleutel en payload. Controleer anders eerst de status van de resource voordat u het opnieuw probeert.

Aanbevolen verversingsschema

Stem de verversingsfrequentie af op uw sleutelbudget en paginagrootte. Een volledige historische load van een grote collectie is een eenmalige kostenpost; geef voor reguliere verversingen de voorkeur aan incrementele vensters, zodat elke run ruim binnen het budget blijft. Stel limit=500 altijd expliciet in; de standaardwaarde van 25 vermenigvuldigt het aantal aanvragen.