Skip to main content
API’et /v1 håndhæver to uafhængige anmodningsbudgetter. En anmodning afvises, hvis et af budgetterne er opbrugt. Budgettet pr. nøgle følger nøglen, uanset hvor den bruges. Budgettet pr. IP er det eneste budget for ikke-godkendt trafik og en ekstra grænse for godkendt trafik.
Grænserne håndhæves før godkendelse, så anmodninger med ugyldige eller manglende legitimationsoplysninger tæller også med i kildens budget. De præcise talværdier konfigureres af operatøren og kan ændre sig; svarkontrakten nedenfor er den stabile grænseflade, som du bør bygge på.
Godkend med en af de to Basic-legitimationsformer – se Quickstart (apikey:secret eller secret:). Sæt BASE til organisationens regionale vært – se Regioner.

429-svaret

Når et budget er opbrugt, returnerer API’et 429 Too Many Requests med en Retry-After-header (i sekunder) og den almindelige problem details-brødtekst:
429 Too Many Requests
Svaret oplyser ikke, hvilket budget der er opbrugt. Behandl alle 429-svar på samme måde: vent, og forsøg derefter igen.

Håndtering af 429-svar

1

Respekter Retry-After

Vent mindst det antal sekunder, der er angivet i Retry-After-headeren, før du forsøger igen. Hvis du forsøger igen tidligere, bruger du blot budget på anmodninger, som alligevel bliver afvist.
2

Brug eksponentiel backoff ved gentagelser

Hvis et nyt forsøg afvises igen, skal du øge din backoff og tilføje tilfældig jitter, så parallelle workers ikke forsøger igen samtidigt. Forkort aldrig serverens Retry-After for at passe til en lokal grænse. Hvis serveren beder dig om at vente længere, end dit budget for nye forsøg tillader, skal du stoppe og planlægge opgaven til senere.
3

Udjævn din anmodningshastighed

Foretræk en jævn anmodningshastighed frem for byger af anmodninger. Ved masseindlæsning skal du bruge den maksimale sidestørrelse (limit=500) for at dække samlingen med færre anmodninger – se paginering. Når flere listegennemløb kører parallelt (for eksempel Power BI-tabeller), skal du holde samtidigheden moderat og respektere Retry-After, så et midlertidigt 429-svar ikke får hele opdateringen til at fejle.
Dette eksempel forsøger kun igen ved 429-svar for en GET-anmodning, med højst fem forsøg og højst 60 sekunders ventetid mellem forsøgene. Det stopper straks ved andre fejl. Netværkstimeouts videregives til kalderen. Konfigurer timeouts og budgetter for nye forsøg, så de passer til din arbejdsbyrde. requests fortolker læsetimeouten som den maksimale inaktivitetstid under modtagelse af data, ikke som en samlet tidsfrist. Indlæs LIVING_SECURITY_API_KEY fra din secret manager. Installer requests, før du kører dette eksempel. Kald get_with_retry("/organization") for at bruge det.
Python
Kopiér ikke denne løkke rundt om en skriveoperation. En timeout efter en skrivning kan betyde, at serveren nåede at gennemføre den, før forbindelsen fejlede. Gentag kun en skrivning, når den pågældende operations reference udtrykkeligt dokumenterer idempotens, og bevar i så fald den samme nøgle og samme nyttelast. Ellers skal du afstemme ressourcens tilstand, før du prøver igen.

Anbefalet opdateringsplan

Afstem opdateringsfrekvensen efter dit nøglebudget og din sidestørrelse. En fuld historisk indlæsning af en stor samling er en engangsomkostning; foretræk inkrementelle vinduer til opdateringer i jævn drift, så hver kørsel holder sig et godt stykke under budgettet. Angiv altid limit=500 eksplicit – standardværdien på 25 øger antallet af anmodninger betydeligt.