Skip to main content
La API de /v1 aplica dos presupuestos de solicitudes independientes. Una solicitud se rechaza si cualquiera de los dos presupuestos se ha agotado. El presupuesto por clave acompaña a la clave dondequiera que se utilice. El presupuesto por IP es el único presupuesto para el tráfico no autenticado y un segundo límite para el tráfico autenticado.
Los límites se aplican antes de la autenticación, por lo que las solicitudes con credenciales no válidas o ausentes también cuentan para el presupuesto del origen. Los presupuestos numéricos exactos los configura el operador y pueden cambiar; el contrato de respuesta que se describe a continuación es la interfaz estable sobre la que debe desarrollar.
Autentíquese con cualquiera de los dos formatos de credenciales Basic; consulte la Guía de inicio rápido (apikey:secret o secret:). Establezca BASE con el host regional de la organización; consulte Regiones.

La respuesta 429

Cuando se agota un presupuesto, la API devuelve 429 Too Many Requests con un encabezado Retry-After (en segundos) y el cuerpo estándar de detalles del problema:
429 Too Many Requests
La respuesta no indica qué presupuesto se ha agotado. Trate todos los 429 de la misma manera: espere y vuelva a intentarlo.

Gestión de las respuestas 429

1

Respete Retry-After

Espere como mínimo el número de segundos indicado en el encabezado Retry-After antes de reintentar. Reintentar antes solo vuelve a consumir presupuesto en solicitudes que serán rechazadas.
2

Aplique un retroceso exponencial en los reintentos repetidos

Si un reintento vuelve a ser rechazado, aumente el tiempo de retroceso y añada una variación aleatoria (jitter) para que los procesos paralelos no reintenten al mismo tiempo. Nunca reduzca el valor de Retry-After del servidor para ajustarlo a un límite local. Si el servidor le pide esperar más de lo que permite su presupuesto de reintentos, deténgase y programe la tarea para más tarde.
3

Suavice su tasa de solicitudes

Es preferible una tasa de solicitudes constante a las ráfagas. Para lecturas masivas, utilice el tamaño de página máximo (limit=500) para cubrir la colección con menos solicitudes; consulte paginación. Cuando se ejecuten varios recorridos de listas en paralelo (por ejemplo, tablas de Power BI), mantenga una concurrencia moderada y respete Retry-After para que un 429 temporal no haga fallar toda la actualización.
Este ejemplo reintenta únicamente las respuestas 429 en una solicitud GET, con un máximo de cinco intentos y un máximo de 60 segundos de espera entre intentos. Se detiene de inmediato ante otros errores. Los tiempos de espera agotados de red se propagan al llamador. Configure los tiempos de espera y los presupuestos de reintentos según su carga de trabajo. requests interpreta el tiempo de espera de lectura como el tiempo máximo de inactividad durante la recepción de datos, no como un plazo global. Cargue LIVING_SECURITY_API_KEY desde su gestor de secretos. Instale requests antes de ejecutar este ejemplo. Llame a get_with_retry("/organization") para utilizarlo.
Python
No copie este bucle alrededor de una operación de escritura. Un tiempo de espera agotado tras una escritura puede significar que el servidor la confirmó antes de que fallara la conexión. Repita una escritura solo cuando la referencia de esa operación documente explícitamente la idempotencia, conservando la misma clave y la misma carga útil. De lo contrario, concilie el estado del recurso antes de volver a intentarlo.

Programación de actualización recomendada

Dimensione la frecuencia de actualización en función del presupuesto de su clave y del tamaño de página. Una carga histórica completa de una colección grande supone un coste único; para las actualizaciones en régimen estable, prefiera ventanas incrementales, de modo que cada ejecución se mantenga muy por debajo del presupuesto. Establezca siempre limit=500 de forma explícita: el valor predeterminado de 25 multiplica el número de solicitudes.