/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.
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 retorna429 Too Many Requests com um
cabeçalho Retry-After (em segundos) e o corpo padrão de detalhes do problema:
429 Too Many Requests
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.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
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 semprelimit=500 explicitamente — o padrão de 25
multiplica o número de requisições.
