Limites atuais
O bucket por token garante que clientes pesados e clientes atrás de NAT compartilhado não penalizem uns aos outros. Combine com o cabeçalho
Idempotency-Key para que retentativas seguras não consumam cota extra — veja Idempotência.
Resposta 429
Quando você excede algum dos limites, a API retorna HTTP429 Too Many Requests com o envelope padrão:
error identifica qual bucket foi atingido (por token ou fallback global por IP).
Cabeçalhos
Toda resposta inclui os cabeçalhos padrão de rate limit;Retry-After é adicionado nas respostas 429.
Tratando 429 no seu cliente
LeiaRetry-After para o tempo mínimo de espera, depois aplique backoff exponencial com jitter começando em 1 segundo:
Boas práticas
- Use
Idempotency-Keypara escritas. Retentativas seguras não consomem cota extra nem criam recursos duplicados. - Agrupe leituras onde possível. Endpoints de listagem paginados são mais eficientes do que múltiplos GETs individuais.
- Faça cache dos dados do catálogo. Planos, regiões e templates de SO mudam raramente — armazene-os localmente em vez de buscar repetidamente.
- Use webhooks para mudanças de estado. Assinar
vm.started,vm.stoppedetc. evita polling em loop emGET /vms/:id. - Precisa de limites maiores? Entre em contato com o suporte — 10 RPS cobre praticamente todas as integrações, mas podemos aumentar os limites por token sob solicitação.