Rate limits

#Um limite dividido com a sua produção

A Resend limita a API a 10 requisições por segundo por time (padrão, pode ser aumentado pedindo à Resend). O limite soma todas as API keys e o acesso OAuth do time. Ou seja, o re: e o seu backend tiram do mesmo balde.

Se um cliente gasta o limite, quem leva o 429 pode ser o seu sistema de produção. O re: foi feito pra não ser esse cliente.

#Como o re: se comporta

• Teto próprio de 4 req/s. O app espaça as requisições em 250 ms, bem abaixo do limite.
• Pausa antes do limite. O app lê ratelimit-remaining e ratelimit-reset de cada resposta. Quando sobram 2 requisições ou menos, ele pausa até a janela renovar.
• Respeita retry-after. Num 429, espera o tempo pedido e tenta de novo no máximo 2 vezes.
• Cache. Listas ficam em cache por 30 a 60 segundos e não são recarregadas a cada troca de tela. Os dados de métricas já vêm com cache de até 15 minutos da própria Resend.
• Sem polling agressivo. Os alertas chegam por webhook, então o app não fica consultando a API em segundo plano.

ratelimit-limit
ratelimit-remaining
ratelimit-reset
retry-after
x-resend-daily-quota
x-resend-monthly-quota

#Uso da API

Em Mais › Uso da API você vê o que as últimas respostas disseram: requisições restantes na janela, quando ela renova, quantas requisições o re: fez no último minuto e as cotas de envio do dia e do mês. A cota diária só existe no plano grátis da Resend.

Com vários times (Pro), cada time tem o próprio limite e a própria cota.

#Quem paga pelas chamadas

As chamadas saem do seu celular, com o seu token, direto pra Resend. Não passam por servidor nosso, então o volume de API não tem custo pra gente e não existe limite artificial do re: em cima do da Resend.

#Quando o time está limitado

Se o seu backend já estiver usando o limite, o re: vai esperar mais. Você vê:

• Um banner Limite da API atingido. Tentando de novo em … com a contagem.
• Se as tentativas acabarem, a tela de erro: A Resend limitou as requisições do seu time por alguns segundos, com Tentar de novo.