/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.
apikey:secret eller secret:).
Ange BASE som organisationens regionala värd – se
Regioner.
Svaret 429
När en budget är förbrukad returnerar API:et429 Too Many Requests med en
Retry-After-header (i sekunder) och den standardiserade problem-details-kroppen:
429 Too Many Requests
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.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
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 alltidlimit=500 uttryckligen – standardvärdet 25 multiplicerar antalet anrop.
