Skip to main content
API:et /v1 tillämpar två oberoende anropsbudgetar. Ett anrop avvisas om någon av budgetarna är förbrukad. Budgeten per nyckel följer med nyckeln oavsett var den används. Budgeten per IP är den enda budgeten för oautentiserad trafik och ett andra tak för autentiserad trafik.
Begränsningarna tillämpas före autentiseringen, så anrop med ogiltiga eller saknade autentiseringsuppgifter räknas också mot källans budget. De exakta numeriska budgetarna konfigureras av operatören och kan ändras; svarskontraktet nedan är det stabila gränssnittet att bygga mot.
Autentisera med någon av de två formerna av Basic-autentiseringsuppgifter – se Snabbstart (apikey:secret eller secret:). Ange BASE som organisationens regionala värd – se Regioner.

Svaret 429

När en budget är förbrukad returnerar API:et 429 Too Many Requests med en Retry-After-header (i sekunder) och den standardiserade problem-details-kroppen:
429 Too Many Requests
Svaret anger inte vilken budget som förbrukats. Behandla alla 429 på samma sätt: vänta och försök sedan igen.

Hantera 429-svar

1

Följ Retry-After

Vänta minst det antal sekunder som anges i headern Retry-After innan du försöker igen. Om du försöker igen tidigare förbrukas bara budget på anrop som ändå kommer att avvisas.
2

Öka väntetiden exponentiellt vid upprepade försök

Om ett nytt försök avvisas igen ska du öka väntetiden och lägga till slumpmässig jitter så att parallella arbetsprocesser inte gör nya försök i takt. Förkorta aldrig serverns Retry-After för att passa en lokal gräns. Om servern ber dig vänta längre än din budget för nya försök tillåter, avbryt och schemalägg arbetet till senare.
3

Jämna ut anropsfrekvensen

Föredra en jämn anropsfrekvens framför stötvisa anropsbursts. För massläsning använder du den största sidstorleken (limit=500) för att täcka samlingen med färre anrop – se paginering. När flera listgenomgångar körs parallellt (till exempel Power BI-tabeller) bör du hålla samtidigheten måttlig och följa Retry-After så att ett tillfälligt 429-svar inte får hela uppdateringen att misslyckas.
Det här exemplet gör nya försök endast för 429-svar på ett GET-anrop, med högst fem försök och högst 60 sekunders väntetid mellan försöken. Det avbryts omedelbart vid andra fel. Nätverkstimeouter vidarebefordras till anroparen. Konfigurera timeouter och budgetar för nya försök efter din arbetsbelastning. requests tolkar läs-timeouten som den längsta tillåtna inaktiva tiden vid mottagning av data, inte som en övergripande tidsgräns. Läs in LIVING_SECURITY_API_KEY från din hemlighetshanterare. Installera requests innan du kör det här exemplet. Anropa get_with_retry("/organization") för att använda det.
Python
Kopiera inte den här loopen till en skrivoperation. En timeout efter en skrivning kan betyda att servern hann genomföra den innan anslutningen bröts. Upprepa en skrivning endast när den operationens referens uttryckligen dokumenterar idempotens, med samma nyckel och samma nyttolast. Annars bör du stämma av resursens tillstånd innan du försöker igen.

Rekommenderat uppdateringsschema

Dimensionera uppdateringsintervallet utifrån din nyckelbudget och sidstorlek. En fullständig historisk inläsning av en stor samling är en engångskostnad; föredra inkrementella tidsfönster för löpande uppdateringar så att varje körning hålls väl under budgeten. Ange alltid limit=500 uttryckligen – standardvärdet 25 multiplicerar antalet anrop.