Skip to main content
API-et /v1 håndhever to uavhengige forespørselsbudsjetter. En forespørsel avvises hvis ett av budsjettene er brukt opp. Budsjettet per nøkkel følger nøkkelen uansett hvor den brukes. Budsjettet per IP er det eneste budsjettet for uautentisert trafikk og en ekstra øvre grense for autentisert trafikk.
Grensene håndheves før autentisering, slik at forespørsler med ugyldig eller manglende legitimasjon også teller mot kildens budsjett. De nøyaktige tallverdiene for budsjettene konfigureres av operatøren og kan endres. Svarkontrakten nedenfor er det stabile grensesnittet du bør bygge på.
Autentiser med en av de to Basic-legitimasjonsformene – se Hurtigstart (apikey:secret eller secret:). Sett BASE til organisasjonens regionale vert – se Regioner.

429-svaret

Når et budsjett er brukt opp, returnerer API-et 429 Too Many Requests med en Retry-After-header (i sekunder) og standard problem-details-innhold:
429 Too Many Requests
Svaret oppgir ikke hvilket budsjett som er brukt opp. Behandle alle 429 på samme måte: vent, og prøv deretter på nytt.

Håndtering av 429-svar

1

Overhold Retry-After

Vent minst det antallet sekunder som står i Retry-After-headeren før du prøver på nytt. Hvis du prøver på nytt tidligere, bruker du bare opp budsjett på forespørsler som uansett vil bli avvist.
2

Bruk eksponentiell backoff ved gjentatte avvisninger

Hvis et nytt forsøk avvises igjen, øker du ventetiden og legger til tilfeldig jitter slik at parallelle arbeidsprosesser ikke prøver på nytt samtidig. Forkort aldri serverens Retry-After for å passe en lokal grense. Hvis serveren ber deg vente lenger enn det forsøksbudsjettet ditt tillater, bør du avslutte og planlegge jobben til et senere tidspunkt.
3

Jevn ut forespørselsraten

Foretrekk en jevn forespørselsrate framfor rykkvise bølger av forespørsler. Ved masseuthenting bruker du maksimal sidestørrelse (limit=500) for å dekke samlingen med færre forespørsler – se paginering. Når flere listegjennomganger kjører parallelt (for eksempel Power BI-tabeller), bør du holde samtidigheten moderat og overholde Retry-After slik at en midlertidig 429 ikke får hele oppdateringen til å mislykkes.
Dette eksempelet prøver bare på nytt ved 429-svar for en GET-forespørsel, med maksimalt fem forsøk og maksimalt 60 sekunders ventetid mellom forsøkene. Det stopper umiddelbart ved andre feil. Nettverkstidsavbrudd sendes videre til den som kaller. Konfigurer tidsavbrudd og forsøksbudsjetter etter din arbeidsbelastning. requests tolker lesetidsavbruddet som maksimal inaktiv tid under mottak av data, ikke som en samlet tidsfrist. Last inn LIVING_SECURITY_API_KEY fra hemmelighetsbehandleren din. Installer requests før du kjører dette eksempelet. Kall get_with_retry("/organization") for å bruke det.
Python
Ikke kopier denne løkken rundt en skriveoperasjon. Et tidsavbrudd etter en skriving kan bety at serveren rakk å lagre endringen før forbindelsen brøt sammen. Gjenta en skriving bare når referansen for den aktuelle operasjonen uttrykkelig dokumenterer idempotens, og bevar den samme nøkkelen og den samme nyttelasten. Ellers må du avstemme ressursens tilstand før du prøver på nytt.

Anbefalt oppdateringsplan

Dimensjoner oppdateringsfrekvensen ut fra nøkkelbudsjettet og sidestørrelsen din. En fullstendig historisk innlasting av en stor samling er en engangskostnad. Foretrekk inkrementelle vinduer for jevnlige oppdateringer, slik at hver kjøring holder seg godt innenfor budsjettet. Angi alltid limit=500 eksplisitt – standardverdien 25 multipliserer antall forespørsler.