- 429 (Too Many Requests) quase sempre pede esperar e tentar de novo, não “forçar” mais rápido
- Backoff exponencial + jitter (aleatoriedade) reduz “tempestade” de requisições simultâneas
- Retentativa sem idempotência cria duplicidade: cobre com chave única/deduplicação
- Concorrência e paginação são tão importantes quanto o retry
- Nem todo erro é retry: 400/401/403 normalmente exigem correção de dados/credencial
1) Identifique o tipo de erro (e não chute)
Separe falhas em três baldes: (a) rate limit/temporário (429, 502, 503, 504, timeouts), (b) credencial/permissão (401/403) e (c) erro de dado/regra (400/422). Só o balde (a) é “candidato natural” a retry. Se você trata tudo como retry, o fluxo vira uma máquina de bater na parede.
2) Respeite o que a API está te dizendo
Muitas APIs enviam headers de limite (ex.: quantidade restante, reset) ou um tempo para tentar novamente (Retry-After). Quando existir, essa é a melhor fonte de verdade. Quando não existir, use uma política conservadora (ex.: esperar alguns segundos e crescer a espera a cada tentativa). Sem número exato? Prefira esperar mais a queimar sua cota e derrubar o resto do dia.
3) Defina uma política de retry com backoff (e teto)
Use backoff exponencial: a cada falha, a espera aumenta (por exemplo: 2s, 4s, 8s...). Adicione jitter (um pequeno fator aleatório) para evitar que vários jobs acordem juntos e causem novo 429. Coloque um limite: número máximo de tentativas e tempo máximo total de espera. Quando estourar, registre e siga para uma fila de reprocessamento, em vez de travar o workflow inteiro.
4) Controle concorrência e crie fila/batch
A causa raiz de rate limit costuma ser paralelismo: múltiplas execuções simultâneas ou loops rápidos demais. Reduza concorrência (um por vez em rotas críticas), processe em lote (batch) e use paginação com pausa. Em automação no-code, isso é o equivalente a “colocar semáforo na rua”: não adianta ter retry perfeito se você continua jogando 200 requisições por segundo.
5) Proteja contra duplicidade com idempotência
Retry pode repetir uma ação que já aconteceu (ex.: criar pedido, enviar mensagem, emitir nota). Sempre que possível, use idempotency key (quando a API suporta) ou crie sua própria trava: registre um identificador único (pedidoId+evento+data) em banco/planilha e cheque antes de criar/enviar de novo. Se não dá para checar, faça o lado “criação” ser o mais idempotente possível (upsert em vez de create).
6) Faça observabilidade mínima: log do erro e do payload
Guarde: status code, endpoint, corpo/erro retornado, tentativa atual, tempo de espera aplicado e um identificador do item (leadId, orderId). Isso encurta debug e evita que o time “tente de novo” às cegas. Quando houver dado sensível, mascare (LGPD).
O que é rate limit (na prática) e por que aparece do nada
Rate limit é uma regra do provedor da API para evitar abuso e manter estabilidade. Ele pode ser por minuto, por segundo, por dia, por token de acesso, por IP, por conta — às vezes tudo ao mesmo tempo.
O motivo de “aparecer do nada” geralmente não é aleatório: pico de tráfego, um loop que aumentou volume, mais gente usando a mesma credencial, ou uma mudança de plano/limite do fornecedor. Automação que funcionava com 300 itens pode quebrar quando vira 3.000.
Retry x Backoff x Jitter: diferenças que mudam o jogo
Retry é tentar novamente. Backoff é esperar mais a cada tentativa. Jitter é bagunçar levemente o tempo de espera para evitar que várias execuções rebatam juntas.
Sem backoff, retry vira martelo pneumático. Sem jitter, seu time cria uma “tempestade sincronizada”: todos falham, todos esperam o mesmo tempo, todos voltam juntos, todos falham de novo.
| Técnica | Serve para | Armadilha comum |
|---|---|---|
| Retry | Recuperar falhas temporárias | Repetir ação não idempotente e gerar duplicidade |
| Backoff (linear/exponencial) | Reduzir pressão na API e aumentar chance de sucesso | Esperar pouco e estourar limite de novo |
| Jitter | Evitar re-tentativas sincronizadas | Jitter grande demais e o fluxo fica lento sem necessidade |
| Limite de concorrência | Controlar volume por segundo/minuto | Esquecer que múltiplos workflows/usuarios compartilham a mesma cota |
Padrão recomendado para n8n, Make e Zapier (independente da ferramenta)
As três plataformas têm jeitos diferentes de configurar, mas o padrão mental é o mesmo: trate integrações como uma esteira com capacidade limitada, não como uma rajada infinita.
Quando você não tem controle fino de headers/limites, compense no seu lado: lotes menores, pausas, e retentativas com teto.
Quando NÃO fazer retry (e o que fazer em vez disso)
Nem todo erro é temporário. Repetir 401 (token inválido) cem vezes só vai gastar tempo e poluir log. Repetir 400 (payload errado) vai só confirmar que o payload continua errado.
A regra simples: erros de autenticação e validação pedem correção; erros de limite e indisponibilidade pedem espera.
| Código/erro | Retry? | Ação típica |
|---|---|---|
| 400/422 (validação) | Não | Corrigir mapeamento/campos; registrar item para análise |
| 401/403 (auth/permissão) | Não | Renovar credencial, revisar escopos/permissões |
| 404 (recurso não encontrado) | Depende | Se é consistência eventual, retry com poucas tentativas; senão, corrigir ID/fluxo |
| 429 (rate limit) | Sim | Esperar (Retry-After se existir) + backoff + reduzir concorrência |
| 5xx/timeout | Sim | Retry com backoff e teto; se persistir, direcionar para fila de reprocessamento |
Perguntas frequentes
Qual é a diferença entre rate limit e quota?
Backoff exponencial é sempre melhor que linear?
Como evitar duplicidade quando faço retry em ações de criação (POST)?
O que mais causa 429 além de volume alto?
Leia também
O que é endpoint em automação e API? Exemplos e usos práticos
Entenda o significado de endpoint em automação e APIs, como funciona na prática e exemplos reais usados por empresas brasileiras. Explicação simples e objetiva para profissionais e iniciantes.
Ler →
Webhook vs API: Qual a Diferença e Exemplos Práticos na Automação
Entenda de forma clara a diferença entre webhook e API, com exemplos do dia a dia na automação de processos. Veja quando faz sentido usar cada um.
Ler →
n8n não executa o workflow? Como achar o erro e depurar de verdade
Aprenda a depurar quando o n8n “não roda”: confirme o trigger, leia a última execução, isole o nó que trava e valide o dado real. Método prático para achar erro de verdade sem chute.
Ler →
Make webhook: como configurar passo a passo (guia 2026)
Configure um webhook no Make (ex-Integromat) do zero em 4 passos: gere a URL HTTPS, determine a estrutura de dados, proteja com API key e evite o erro de fila cheia. Guia em português.
Ler →