—Documentação
Rate limits.
Limites por chave, não por workspace. Sandbox tem teto reduzido para incentivar testes em produção. Limites são publicados em todas as respostas.
Limites por plano
| Plano | Por segundo | Burst |
|---|---|---|
| Sandbox | 5 | 10 |
| Dev | 10 | 20 |
| Starter | 25 | 50 |
| Growth | 60 | 120 |
| Business | 150 | 300 |
| Scale | 400 | 800 |
| Unlimited | 1.000 | 2.000 |
| Enterprise | negociado | negociado |
O burst absorve picos curtos. Sustentar acima do limite por mais de alguns segundos resulta em 429.
Cabeçalhos de resposta
Toda resposta (sucesso ou erro) inclui o estado atual do bucket de tokens:
cabeçalhos
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 47
X-RateLimit-Reset: 1729184832
Retry-After: 1X-RateLimit-Limit— limite por segundo da chave.X-RateLimit-Remaining— tokens disponíveis no balde agora.X-RateLimit-Reset— timestamp Unix do próximo refill.Retry-After— só aparece em429; segundos antes de tentar novamente.
Boas práticas
- → Distribua requisições no tempo em vez de mandar em rajada.
- → Respeite
Retry-Afterao invés de retentar imediato. - → Use chaves separadas para batch jobs e tráfego online — limites são por chave.
- → Para batches grandes, contrate Unlimited ou Enterprise.
Ignorar
429 e retentar agressivamente pode resultar em bloqueio temporário da chave. Use backoff exponencial.