Skip to main content
A API pública da VMArea usa dois buckets encadeados, ambos com Redis como backend — os limites são compartilhados entre todas as instâncias da API.

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 HTTP 429 Too Many Requests com o envelope padrão:
A string 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

Leia Retry-After para o tempo mínimo de espera, depois aplique backoff exponencial com jitter começando em 1 segundo:

Boas práticas

  • Use Idempotency-Key para 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.stopped etc. evita polling em loop em GET /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.