Skip to main content
A API /v1 aplica dois orçamentos de solicitações independentes. Uma solicitação é recusada se qualquer um dos orçamentos estiver esgotado. O orçamento por chave acompanha a chave onde quer que ela seja utilizada. O orçamento por IP é o único orçamento para o tráfego não autenticado e um segundo limite para o tráfego autenticado.
Os limites são aplicados antes da autenticação; portanto, as solicitações com credenciais inválidas ou ausentes também são contabilizadas no orçamento da origem. Os orçamentos numéricos exatos são configurados pelo operador e podem mudar; o contrato de resposta descrito abaixo é a interface estável sobre a qual você deve desenvolver.
Autentique-se com qualquer um dos formatos de credencial Basic — consulte o Guia de início rápido (apikey:secret ou secret:). Defina BASE como o host regional da organização — consulte Regiões.

A resposta 429

Quando um orçamento é esgotado, a API retorna 429 Too Many Requests com um cabeçalho Retry-After (em segundos) e o corpo padrão de detalhes do problema:
429 Too Many Requests
A resposta não informa qual orçamento foi esgotado. Trate todas as respostas 429 da mesma forma: aguarde e, em seguida, tente novamente.

Tratamento de respostas 429

1

Respeite o Retry-After

Aguarde pelo menos o número de segundos indicado no cabeçalho Retry-After antes de tentar novamente. Repetir a solicitação antes disso apenas consome novamente o orçamento com solicitações que serão recusadas.
2

Aplique recuo exponencial em caso de repetição

Se uma nova tentativa for recusada novamente, aumente o intervalo de recuo e adicione um jitter aleatório para que os processos paralelos não repitam as solicitações de forma sincronizada. Nunca reduza o Retry-After do servidor para se ajustar a um limite local. Se o servidor solicitar uma espera maior do que o seu orçamento de novas tentativas permite, interrompa o processo e agende o trabalho para mais tarde.
3

Suavize a taxa de solicitações

Prefira uma taxa de solicitações constante a picos de tráfego. Para leituras em massa, use o tamanho máximo de página (limit=500) para percorrer a coleção com menos solicitações — consulte paginação. Quando várias listagens forem percorridas em paralelo (por exemplo, tabelas do Power BI), mantenha a simultaneidade moderada e respeite Retry-After para que um 429 temporário não faça toda a atualização falhar.
Este exemplo repete apenas respostas 429 para uma solicitação GET, com no máximo cinco tentativas e no máximo 60 segundos de espera entre elas. Ele é interrompido imediatamente em caso de outros erros. Os tempos limite de rede são propagados ao chamador. Configure os tempos limite e os orçamentos de novas tentativas de acordo com a sua carga de trabalho. requests interpreta o tempo limite de leitura como o tempo máximo de inatividade durante o recebimento de dados, e não como um prazo total. Carregue LIVING_SECURITY_API_KEY a partir do seu gerenciador de segredos. Instale requests antes de executar este exemplo. Chame get_with_retry("/organization") para utilizá-lo.
Python
Não reutilize este loop em torno de uma operação de gravação. Um tempo limite após uma gravação pode significar que o servidor a confirmou antes de a conexão falhar. Repita uma gravação somente quando a referência dessa operação documentar explicitamente a idempotência, preservando a mesma chave e o mesmo payload. Caso contrário, reconcilie o estado do recurso antes de tentar novamente.

Cronograma de atualização recomendado

Dimensione a frequência de atualização de acordo com o orçamento da sua chave e o tamanho da página. Uma carga histórica completa de uma coleção grande representa um custo único; prefira janelas incrementais para as atualizações regulares, de modo que cada execução permaneça bem abaixo do orçamento. Defina sempre limit=500 explicitamente — o padrão de 25 multiplica o número de solicitações.