Erro 429 no Power Automate: causas e como corrigir
O erro 429 não significa que o seu fluxo está errado: significa que ele pediu demais, rápido demais. Veja como descobrir qual limite foi atingido e o que mudar, em ordem de eficácia.
O que o erro 429 significa
429 TooManyRequests é a resposta de um serviço que recusa pedidos porque chegaram mais do que ele aceita em um intervalo de tempo. O pedido em si está correto; ele foi enviado com frequência demais. No Power Automate a mensagem costuma ser parecida com Rate limit is exceeded. Try again in 27 seconds.
A boa notícia: quase sempre dá para resolver sem refazer o fluxo. A má: aumentar o paralelismo "para ir mais rápido" costuma piorar.
Passo 1: descubra qual limite você atingiu
Há mais de um tipo de limite, e cada um tem uma correção diferente:
| Sintoma | Limite | O que ajuda |
|---|---|---|
| 429 em um conector específico, com "Rate limit is exceeded" | Limite do conector | Espaçar as chamadas, agrupá-las em lote ou reduzir a concorrência |
| Ações atrasadas no fluxo inteiro e muitas ações por dia | Limite diário de ações | Menos requisições, ou mais capacidade de licença (fale com o administrador) |
| Erros ao chamar o Dataverse sob carga | Proteção de serviço do Dataverse | Reduzir a taxa de requisições |
Exemplo de limite de conector: o do SharePoint aceita cerca de 600 operações por minuto por conexão, e a mesma conexão usada em vários fluxos soma no mesmo limite. Isso explica por que um fluxo "inocente" falha quando outro roda ao mesmo tempo.
Passo 2: reduza a concorrência
Esta é a correção que a própria documentação da Microsoft indica primeiro. O Aplicar a cada (Apply to each) roda um item por vez por padrão; se alguém ativou a concorrência (de 1 a 50), todos esses itens passam a chamar o serviço ao mesmo tempo.
- No Aplicar a cada, clique em ... e em Configurações.
- Em Controle de simultaneidade, reduza o grau de paralelismo (use 1 para processar um item por vez).
- Se o fluxo é iniciado por um gatilho que recebe muitos eventos (por exemplo, arquivos criados em uma pasta), faça o mesmo nas configurações do gatilho.
Passo 3: faça menos requisições
Toda ação conta como requisição, inclusive as internas, como inicializar variável ou compor. Retentativas e paginação também contam. Reduções que costumam funcionar:
- Condições de gatilho: o fluxo só roda quando o item realmente interessa. Um fluxo que dispara para todo e-mail e só depois verifica o remetente gasta requisições em todos.
- Filtrar na origem: use a consulta de filtro (OData) no conector em vez de trazer tudo e testar item por item dentro de um loop.
- Selecionar e Filtrar matriz no lugar de loops quando você só está transformando dados, não agindo em cada item.
- Retire retentativas que não ajudam: cada uma conta como ação.
Conta de padaria: uma loja de material de construção atualiza 3.000 itens de estoque em uma lista do SharePoint, um item por ação. Com o limite de 600 operações por minuto, o mínimo teórico é 3.000 ÷ 600 = 5 minutos. Se o fluxo tentar fazer tudo em 1 minuto com paralelismo 50, a chance de tomar 429 é alta. O caminho certo é aceitar os 5 minutos (ou mais) e desenhar o fluxo para isso.
Passo 4: espace as chamadas e repita com critério
Dentro de um loop sequencial, uma ação Atraso (Delay) entre as chamadas deixa o fluxo abaixo do limite do conector.
Para falhas passageiras, configure a política de repetição na ação (... > Configurações > Política de repetição):
- A Microsoft recomenda a política exponencial: o intervalo cresce a cada tentativa, o que dá tempo ao serviço para se recuperar.
- Você define a quantidade de repetições e o intervalo em formato ISO 8601, por exemplo
PT30Spara 30 segundos. Na documentação da plataforma, a quantidade vai de 1 a 90. - Na política padrão da maioria das operações, são até 4 repetições com intervalos crescentes entre 5 e 45 segundos.
O SharePoint Online devolve junto do 429 o cabeçalho Retry-After, com quantos segundos esperar. A Microsoft avisa que ignorar essa espera pode aumentar o tempo de bloqueio, e quem insiste em exceder os limites pode ser bloqueado de vez.
Passo 5: use operações em lote quando existirem
Para criar ou atualizar milhares de registros, a documentação desaconselha um loop item a item. Conectores e APIs que aceitam lote permitem agrupar várias operações em uma única requisição (por exemplo, o lote da API REST do SharePoint chamado por uma ação HTTP). No Dataverse existem as operações em massa (bulk), que contam como uma operação só.
O que não fazer
- Não aumentar a concorrência para "acelerar" um fluxo que já toma 429.
- Não configurar repetições sem espaçamento: elas contam como ações e pioram o problema.
- Não dividir o mesmo volume em vários fluxos que usam a mesma conexão: o limite do conector é por conexão.
Checklist rápido
- Li a mensagem completa do erro e identifiquei o conector.
- Reduzi o paralelismo do loop e do gatilho.
- Adicionei condição de gatilho e filtro na origem.
- Troquei loops por Selecionar/Filtrar matriz onde era só transformação.
- Configurei política de repetição exponencial e, se preciso, um Atraso.
- Calculei o tempo mínimo (itens ÷ limite por minuto) e aceitei esse prazo.
Ferramentas para usar com este guia
Fontes oficiais
- Too many requests error in Power Automate (Microsoft Learn)
- Understand platform limits and avoid throttling (Microsoft Learn)
- Optimize flows with parallel execution and concurrency (Microsoft Learn)
- Employ robust error handling: retry policy (Microsoft Learn)
- Retry policies (Azure Logic Apps, base do Power Automate)
- Avoid getting throttled or blocked in SharePoint Online