Skip to main content
A API /v1 aplica dois orçamentos de requisições independentes. Uma requisição é recusada se qualquer um dos orçamentos estiver esgotado. O orçamento por chave acompanha a chave onde quer que ela seja usada. 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, requisiçõ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 na qual você deve basear sua implementação.
Autentique-se com qualquer um dos dois formatos de credencial Basic — consulte o Quickstart (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 todo 429 da mesma forma: aguarde e 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. Tentar novamente antes disso apenas consome orçamento novamente com requisições que serão recusadas.
2

Aplique backoff exponencial em caso de repetição

Se uma nova tentativa for recusada novamente, aumente o intervalo de backoff e adicione jitter aleatório para que workers paralelos não repitam as tentativas de forma sincronizada. Nunca reduza o Retry-After do servidor para se ajustar a um limite local. Se o servidor solicitar que você aguarde mais do que o seu orçamento de novas tentativas permite, interrompa e agende o trabalho para mais tarde.
3

Suavize a taxa de requisições

Prefira uma taxa de requisições constante a rajadas. Para leituras em massa, use o tamanho máximo de página (limit=500) para percorrer a coleção com menos requisições — consulte paginação. Quando várias leituras de listas forem executadas em paralelo (por exemplo, tabelas do Power BI), mantenha a concorrência moderada e respeite Retry-After para que um 429 temporário não faça toda a atualização falhar.
Este exemplo tenta novamente apenas respostas 429 em uma requisiçã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 timeouts de rede são propagados ao chamador. Configure os timeouts e os orçamentos de novas tentativas de acordo com a sua carga de trabalho. requests interpreta o timeout 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 usá-lo.
Python
Não copie este loop para uma operação de gravação. Um timeout 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 com base no orçamento da sua chave e no tamanho da página. Uma carga histórica completa de uma coleção grande é um custo único; prefira janelas incrementais para atualizações em regime estável, de modo que cada execução fique bem abaixo do orçamento. Defina sempre limit=500 explicitamente — o padrão de 25 multiplica o número de requisições.