Rate limit e retry no n8n: como parar de ser bloqueado pelas APIs

Erro 429 significa que você fez requisições demais em pouco tempo. Não é defeito do seu fluxo — é a API se protegendo. A solução tem três camadas: espaçar as requisições, tentar de novo quando falhar e, quando possível, pedir menos. Este texto mostra as três, e por que a segunda sozinha piora o problema.

Por que isso acontece com automação

Um humano usando o sistema faz talvez uma requisição a cada poucos segundos. Um fluxo com 500 itens dispara 500 requisições o mais rápido que conseguir.

Lembre da mecânica do n8n: o node processa cada item individualmente. Se o node anterior devolveu 500 registros, o node de requisição vai chamar a API 500 vezes, em sequência e sem pausa. Do lado de lá, isso é indistinguível de um ataque.

Camada 1: espaçar

A primeira e mais eficaz. Se a API permite 60 requisições por minuto, uma pausa de pouco mais de um segundo entre elas mantém o fluxo dentro do limite para sempre.

Duas formas de conseguir isso:

• Processar em lotes com pausa entre eles — trata vinte registros, espera, trata os próximos vinte.

• Node de espera dentro do laço, criando o intervalo entre uma requisição e a seguinte.

Parece contraintuitivo deixar o fluxo mais lento de propósito. Mas um fluxo que leva dez minutos e termina é melhor que um que leva dois e falha na metade.

Procure na documentação da API o limite exato antes de chutar. Muitas informam em cabeçalhos da própria resposta quantas requisições ainda restam na janela atual — dá para ler esse valor e ajustar o ritmo.

Camada 2: tentar de novo, com espera crescente

Falha acontece mesmo com espaçamento: um pico de uso, uma instabilidade do outro lado. Nesse caso, tentar de novo resolve.

Mas há um detalhe que separa quem resolve de quem piora:

Repetir imediatamente é a pior reação possível a um 429. Você foi barrado por excesso de requisições e responde com mais requisições. Muitos serviços aumentam a punição nesse caso — o que era um bloqueio de segundos vira de minutos. A repetição precisa vir com espera crescente: falhou, espera um pouco; falhou de novo, espera o dobro.

Vale distinguir o que merece nova tentativa:

Repetir cegamente qualquer erro desperdiça tempo e execuções em casos que nunca vão funcionar.

Camada 3: pedir menos

A camada mais esquecida e frequentemente a mais eficaz.

Filtre antes. Se você busca mil registros e usa cinquenta, filtre na origem. São 950 requisições que deixam de existir.

Prefira operações em lote. Muitas APIs aceitam criar ou atualizar vários registros numa requisição só. Cem chamadas viram uma.

Guarde o que não muda. Se o fluxo consulta a mesma tabela de referência a cada item, busque uma vez no começo e reutilize.

Seja avisado em vez de perguntar. Trocar um fluxo que verifica de minuto em minuto por um webhook elimina milhares de requisições por mês — e o dado chega na hora, o que é melhor para todo mundo.

Quando o item problemático não pode parar o resto

Fluxo com 500 itens em que o de número 37 falha: o comportamento padrão interrompe tudo. Às vezes é o certo — numa operação financeira, parar é mais seguro que seguir pela metade.

Em outros casos não é. Se você está enviando avisos e um endereço está inválido, faz mais sentido registrar aquele caso e continuar os outros 499. Os nodes permitem configurar esse comportamento, e a escolha depende de o processo tolerar resultado parcial ou não.

A pergunta que orienta: parar no meio deixa o sistema num estado pior do que seguir? Se sim, pare. Se não, continue e registre.

Espaçar, tentar de novo com espera crescente e pedir menos. E nunca responder a um 429 com repetição imediata.

Perguntas frequentes