Skip to main content
API-ul /v1 aplică două bugete de solicitări independente. O solicitare este refuzată dacă oricare dintre bugete este epuizat. Bugetul per cheie urmărește cheia oriunde este utilizată. Bugetul per IP este singurul buget pentru traficul neautentificat și o a doua limită pentru traficul autentificat.
Limitele sunt aplicate înainte de autentificare, astfel că solicitările cu credențiale nevalide sau lipsă se contorizează, de asemenea, în bugetul sursei. Valorile numerice exacte ale bugetelor sunt configurate de operator și pot fi modificate; contractul răspunsului de mai jos este interfața stabilă pe care trebuie să vă bazați.
Autentificați-vă cu oricare dintre formele de credențiale Basic — consultați Ghid de pornire rapidă (apikey:secret sau secret:). Setați BASE la gazda regională a organizației — consultați Regiuni.

Răspunsul 429

Când un buget este epuizat, API-ul returnează 429 Too Many Requests cu un antet Retry-After (în secunde) și corpul standard problem-details:
429 Too Many Requests
Răspunsul nu precizează care buget a fost epuizat. Tratați fiecare 429 în același mod: așteptați, apoi reîncercați.

Gestionarea răspunsurilor 429

1

Respectați Retry-After

Așteptați cel puțin numărul de secunde din antetul Retry-After înainte de a reîncerca. O reîncercare mai devreme consumă din nou din buget pentru solicitări care vor fi refuzate.
2

Măriți exponențial intervalul de așteptare la repetări

Dacă o reîncercare este refuzată din nou, măriți intervalul de așteptare și adăugați un jitter aleatoriu astfel încât procesele paralele să nu reîncerce sincronizat. Nu scurtați niciodată valoarea Retry-After a serverului pentru a respecta o limită locală. Dacă serverul vă cere să așteptați mai mult decât permite bugetul dvs. de reîncercări, opriți-vă și programați lucrarea pentru mai târziu.
3

Uniformizați rata solicitărilor

Preferați o rată constantă a solicitărilor în locul vârfurilor. Pentru citiri în masă, utilizați dimensiunea maximă a paginii (limit=500) pentru a acoperi colecția cu mai puține solicitări — consultați paginare. Când mai multe parcurgeri de liste rulează în paralel (de exemplu, tabele Power BI), păstrați un nivel moderat de concurență și respectați Retry-After, astfel încât un 429 temporar să nu ducă la eșecul întregii reîmprospătări.
Acest exemplu reîncearcă doar răspunsurile 429 pentru o solicitare GET, cu cel mult cinci încercări și cel mult 60 de secunde de așteptare între încercări. Se oprește imediat la alte erori. Expirările de timp de rețea sunt propagate către apelant. Configurați expirările de timp și bugetele de reîncercări în funcție de volumul dvs. de lucru. requests interpretează timpul limită de citire ca timpul maxim de inactivitate la primirea datelor, nu ca termen limită total. Încărcați LIVING_SECURITY_API_KEY din managerul dvs. de secrete. Instalați requests înainte de a rula acest exemplu. Apelați get_with_retry("/organization") pentru a-l utiliza.
Python
Nu copiați această buclă în jurul unei operații de scriere. O expirare a timpului după o scriere poate însemna că serverul a confirmat-o înainte ca、conexiunea să eșueze. Repetați o scriere numai dacă referința acelei operații documentează explicit idempotența, păstrând aceeași cheie și aceleași date. În caz contrar, reconciliați starea resursei înainte de a încerca din nou.

Program de reîmprospătare recomandat

Dimensionați frecvența reîmprospătării în funcție de bugetul cheii și de dimensiunea paginii. O încărcare istorică completă a unei colecții mari este un cost unic; preferați ferestre incrementale pentru reîmprospătările în regim stabil, astfel încât fiecare rulare să rămână cu mult sub buget. Setați întotdeauna limit=500 în mod explicit — valoarea implicită de 25 multiplică numărul de solicitări.