Skip to main content
L’API /v1 aplica dos pressupostos de sol·licituds independents. Una sol·licitud es rebutja si qualsevol dels dos pressupostos s’ha esgotat. El pressupost per clau segueix la clau allà on s’utilitzi. El pressupost per IP és l’únic pressupost per al trànsit no autenticat i un segon límit per al trànsit autenticat.
Els límits s’apliquen abans de l’autenticació; per tant, les sol·licituds amb credencials no vàlides o absents també compten contra el pressupost d’origen. Els pressupostos numèrics exactes els configura l’operador i poden canviar; el contracte de resposta que es descriu a continuació és la interfície estable sobre la qual podeu desenvolupar.
Autentiqueu-vos amb qualsevol de les dues modalitats de credencial Basic; consulteu Quickstart (apikey:secret o secret:). Configureu BASE amb l’amfitrió regional de l’organització; consulteu Regions.

La resposta 429

Quan un pressupost s’esgota, l’API retorna 429 Too Many Requests amb una capçalera Retry-After (en segons) i el cos estàndard de detalls del problema:
429 Too Many Requests
La resposta no indica quin pressupost s’ha esgotat. Tracteu tots els 429 de la mateixa manera: espereu i torneu-ho a intentar.

Gestió dels 429

1

Respecteu Retry-After

Espereu, com a mínim, el nombre de segons indicat a la capçalera Retry-After abans de tornar-ho a intentar. Reintentar-ho abans només torna a consumir pressupost en sol·licituds que es rebutjaran.
2

Apliqueu un retard exponencial en cas de repeticions

Si un reintent es rebutja de nou, augmenteu el retard i afegiu-hi un jitter aleatori perquè els processos paral·lels no reintentin de manera sincronitzada. No escurceu mai el Retry-After del servidor per ajustar-lo a un límit local. Si el servidor us demana que espereu més del que permet el vostre pressupost de reintents, atureu-vos i programeu la feina per a més tard.
3

Suavitzeu la vostra taxa de sol·licituds

És preferible una taxa de sol·licituds constant a les ràfegues. Per a lectures massives, utilitzeu la mida de pàgina màxima (limit=500) per cobrir la col·lecció amb menys sol·licituds; consulteu pagination. Quan diversos recorreguts de llistes s’executen en paral·lel (per exemple, taules de Power BI), mantingueu una concurrència moderada i respecteu Retry-After perquè un 429 temporal no faci fallar tota l’actualització.
Aquest exemple només reintenta les respostes 429 en una sol·licitud GET, amb un màxim de cinc intents i un màxim de 60 segons d’espera entre intents. S’atura immediatament davant d’altres errors. Els temps d’espera de xarxa es propaguen a qui fa la crida. Configureu els temps d’espera i els pressupostos de reintents segons la vostra càrrega de treball. requests interpreta el temps d’espera de lectura com el temps màxim d’inactivitat durant la recepció de dades, no com un termini global. Carregueu LIVING_SECURITY_API_KEY des del vostre gestor de secrets. Instal·leu requests abans d’executar aquest exemple. Crideu get_with_retry("/organization") per utilitzar-lo.
Python
No copieu aquest bucle al voltant d’una operació d’escriptura. Un temps d’espera esgotat després d’una escriptura pot significar que el servidor la va confirmar abans que la connexió fallés. Repetiu una escriptura només quan la referència d’aquesta operació documenti explícitament la idempotència, conservant la mateixa clau i la mateixa càrrega. En cas contrari, concilieu l’estat del recurs abans de tornar-ho a intentar.

Calendari d’actualització recomanat

Dimensioneu la cadència d’actualització segons el pressupost de la vostra clau i la mida de pàgina. Una càrrega històrica completa d’una col·lecció gran és un cost únic; per a les actualitzacions en règim estacionari, són preferibles les finestres incrementals, de manera que cada execució quedi ben per sota del pressupost. Configureu sempre limit=500 de manera explícita: el valor per defecte de 25 multiplica el nombre de sol·licituds.