> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Limites de taxa

> Orçamentos de solicitações da API Pública da Living Security, o contrato da resposta 429 e como repetir a solicitação com Retry-After.

A API `/v1` aplica dois orçamentos de solicitações independentes. Uma solicitação
é recusada se qualquer um dos orçamentos estiver esgotado.

| Orçamento | Aplica-se a |
| - | - |
| Por chave de API | Todas as solicitações que apresentam essa chave, a partir de qualquer endereço |
| Por IP do cliente | Todas as solicitações provenientes desse endereço, autenticadas ou não |

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.

<Note>
  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.
</Note>

Autentique-se com qualquer um dos formatos de credencial Basic — consulte o
[Guia de início rápido](/pt/developers/v1/quickstart) (`apikey:secret` ou `secret:`).
Defina `BASE` como o host regional da organização — consulte
[Regiões](/pt/developers/v1/regions).

## 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:

```json 429 Too Many Requests theme={null}
{
  "type": "https://docs.livingsecurity.com/developers/v1/errors/rate_limited",
  "title": "Too Many Requests",
  "status": 429,
  "detail": "Rate limit exceeded. Retry after the Retry-After interval.",
  "code": "rate_limited",
  "request_id": "req_...",
  "doc_url": "https://docs.livingsecurity.com/developers/v1/errors/rate_limited",
  "retryable": true
}
```

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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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](/pt/developers/v1/pagination). 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.
  </Step>
</Steps>

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 Python theme={null}
import os
import random
import time
import requests

# US: BASE = "https://api.us-east-1.livingsecurity.ai/v1"
BASE = "https://api.eu-west-1.livingsecurity.ai/v1"
AUTH = ("apikey", os.environ["LIVING_SECURITY_API_KEY"])

def get_with_retry(path, params=None, max_attempts=5):
    if not 1 <= max_attempts <= 5:
        raise ValueError("max_attempts must be between 1 and 5")
    for attempt in range(max_attempts):
        response = requests.get(
            f"{BASE}{path}", auth=AUTH, params=params,
            headers={"Living-Security-Version": "2026-07-01"},
            timeout=(5, 30), allow_redirects=False,
        )
        if response.status_code != 429:
            response.raise_for_status()
            if not 200 <= response.status_code < 300:
                raise RuntimeError("Unexpected redirect; check your regional API URL")
            return response

        # The API returns Retry-After as a whole number of seconds.
        raw_wait = response.headers.get("Retry-After", "")
        request_id = response.headers.get("Request-Id", "unknown")
        response.close()
        if attempt == max_attempts - 1:
            raise RuntimeError(f"Retry budget exhausted; request_id={request_id}")
        if not raw_wait.isascii() or not raw_wait.isdigit() or len(raw_wait) > 6:
            raise RuntimeError(f"Invalid Retry-After; request_id={request_id}")

        wait = max(int(raw_wait), min(2 ** attempt, 30))
        delay = wait + random.uniform(0, 1)
        if delay > 60:
            raise RuntimeError(f"Retry-After exceeds wait budget; request_id={request_id}")
        time.sleep(delay)
```

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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.