Rate limits

A Aeses aplica rate limits por chave para proteger a plataforma e garantir uso justo. Os limites valem independentemente para chaves de teste e live.

Limites padrão

| Plano | Leitura (GET) | Escrita (POST/DELETE) | | ---------- | --------------- | ------------------------- | | Standard | 100 req/s | 25 req/s | | Scale | 500 req/s | 100 req/s | | Enterprise | Customizado | Customizado |

Bursts de até 2× o limite estável são tolerados por janelas curtas.

Inspecionando seus limites

Toda resposta inclui estes headers:

| Header | Descrição | | ----------------------- | --------------------------------------------------------------- | | X-RateLimit-Limit | Máximo de requisições permitidas na janela atual. | | X-RateLimit-Remaining | Requisições restantes na janela atual. | | X-RateLimit-Reset | Timestamp Unix (segundos) em que a janela reseta. | | Retry-After | Presente em respostas 429. Segundos a esperar antes do retry. |

Atingindo o limite

Quando você excede o limite, a Aeses responde com 429 rate_limit_error:

Resposta de rate-limit

{
"error": {
  "type": "rate_limit_error",
  "code": "rate_limited",
  "message": "Too many requests. Retry after 1.2 seconds.",
  "request_id": "req_01HXYZ..."
}
}

A resposta inclui o header Retry-After. Aguarde pelo menos esse tempo antes de refazer. Combine com backoff exponencial para evitar retries em manada num pico transiente.

Desenhando em torno dos limites

Batch quando possível. Use os endpoints de listagem com limit=100 em vez de fazer polling em recursos individuais.
Assine, não faça polling. Escute webhooks em vez de fazer polling no status de deposit/withdrawal.
Cacheie leituras. Dados de saldo e conta mudam pouco — cacheie por pelo menos 10 segundos.
Chaves separadas por workload. Use chaves diferentes para tráfego síncrono voltado ao usuário e para reconciliação em background, evitando que um job pesado roube banda do checkout.

Se você bate o limite com frequência, peça um aumento em Painel → Developers → Plan limits.