Retome com backoff e a mesma intenção
Limites protegem conta, provedor e destinatários. Quando Retry-After estiver presente, ele deve orientar a próxima tentativa.
Cabeçalhos de limite da API REST
O Mandaí publica uma API REST/JSON, sem GraphQL. Rotas protegidas de envio e preview anunciam RateLimit-Policy: "message";q=120;w=60. Outras mutações e autenticação usam 30 requisições por 60 segundos. O bucket de ingresso usa o IP fornecido pela Cloudflare, não a chave de API, e a aplicação é local à infraestrutura de rate limiting da Cloudflare.
Os campos RateLimit-Policy e RateLimit seguem draft-ietf-httpapi-ratelimit-headers-11 (Internet-Draft, ainda não um RFC). Ao esgotar a quota, a resposta HTTP 429 inclui RateLimit: "message";r=0;t=60 e Retry-After: 60. Respeite Retry-After antes de tentar novamente. A falha do limitador retorna 503 e Retry-After, sem afirmar quota esgotada.
A binding não informa o contador restante nas chamadas permitidas; por isso essas respostas publicam a política, sem inventar um valor de remaining. Rotas de leitura sem limitador não anunciam uma quota. Cabeçalhos são expostos via CORS aos clientes autorizados.
Comportamento recomendado
- Respeite Retry-After.
- Aplique backoff exponencial com jitter.
- Preserve a mesma Idempotency-Key para o mesmo comando.
- Não distribua chaves para contornar uma política de limite.