Skip to main content
Os rate limits ficam nos endpoints que um atacante alcança sem credencial — os que adivinham senhas, enumeram endereços ou mandam e-mail em nome de outra pessoa. A contagem é uma janela fixa por IP do cliente, exceto o boot, que é adicionalmente contado por chave publicável.

Ao ser limitado

429
Retry-After carrega a janela em segundos. Espere; tentar antes só consome a próxima janela.

Os limites

Autenticação de staff

Convites

Plano de clientes

O limite por chave no boot existe porque a chave publicável é a fronteira de tenant por onde uma enxurrada chega: bots e tráfego de landing page criariam linhas de visitante para sempre.

A superfície do próprio contato

Por sessão, não por IP. Atrás do NAT de uma operadora um endereço é milhares de pessoas, então um balde por IP numa superfície autenticada limita uma multidão pelo que um deles fez — e a sessão é o que de fato gasta o trabalho. O /v1/contact/token é a razão de o número existir: cada chamada é um decrypt de chave e uma assinatura.
As demais rotas autenticadas — tudo atrás de uma sessão de staff ou de uma chave de API — não têm throttle. A credencial é o portão, e ela é revogável.

Falhar aberto, falhar fechado

Duas posturas, escolhidas por endpoint. Os contadores vivem num store compartilhado por todas as instâncias da API. Quando esse store não pode ser alcançado, cada instância passa a contar sozinha — os limites continuam existindo e ficam mais frouxos, em vez de sumirem. Isso é deliberado, e é o único lugar onde esta plataforma não degrada graciosamente. Todo o resto que é opcional se desliga sem a sua dependência; um cadastro público atrás de limitador nenhum é a postura de segurança inteira desligada em silêncio, exatamente no momento em que um atacante é a explicação mais provável. O que você pode notar enquanto durar: um limite permitindo, por pouco tempo, um pouco mais que o número acima, porque várias instâncias estão contando até ele cada uma. Nada responde diferente, e não há nada para tratar.

Ficando abaixo deles

1

Faça retry em 429, com backoff

Respeite Retry-After quando ele vier; use backoff exponencial quando não vier.
2

Não faça retry de um 4xx que não seja 429

Um 400 ou um 403 vai responder igual todas as vezes.
3

Faça debounce do boot

Um boot por carregamento de página, não um por componente que queira o contato.
4

Limite os seus próprios botões de reenvio

Reenvios de verificação e de magic link são 5 por hora. Um botão sem cooldown queima isso em segundos e o usuário só vê falha.