Falhou? Tenta de novo sozinho
Uma tarefa que falha é tentada de novo após esperas crescentes, como 1, 2, 4 e 8 segundos, até funcionar ou esgotar as tentativas. Se 3 de 10.000 linhas nunca vão dar certo, elas ficam separadas e as outras 9.997 seguem em frente.
O flow.retry refaz sozinho uma tarefa que falhou por motivo passageiro — rede que oscilou, serviço que ficou um instante fora do ar. Em vez de o seu código tratar cada tropeço, a nova tentativa acontece automática, com espera que cresce a cada rodada para não insistir na hora errada.
Nem toda falha é para valer
Boa parte dos erros de integração é passageira: a rede piscou, o serviço do outro lado reiniciou, um limite momentâneo foi batido. Tentar de novo trinta segundos depois costuma resolver — e é exatamente o que um humano faria. O problema é encher o seu código de laços de tentativa, contadores e esperas, espalhados por cada chamada frágil.
O retry automático concentra esse hábito num lugar só: você marca a tarefa como “vale insistir” e ele insiste por você.
Esperar mais a cada tentativa
Insistir na lata piora as coisas — se o serviço caiu por excesso de carga, martelar sem parar só afunda mais. Por isso a nova tentativa espera cada vez mais entre uma rodada e outra: alguns segundos, depois mais, depois mais ainda, dando tempo de o outro lado se recuperar. Você define quantas tentativas no máximo e o retry para quando o teto é atingido, sem ficar batendo para sempre numa porta que não vai abrir.
Onde o retry se encaixa
Ele brilha nas pontas frágeis dos seus fluxos. Combinado com o encadeamento, é o que faz a diferença entre um fluxo que quebra no primeiro tropeço e um que aguenta a vida real da internet.
Preço, e quando não vale insistir
Uma tarefa que acerta de primeira custa uma; uma que precisou de três rodadas até dar certo custa três. Por isso o teto de tentativas importa: ele evita gastar à toa numa falha que não é passageira. Erro de dado — um CPF inválido, um arquivo corrompido — não melhora com insistência; para esses, o certo é falhar logo e avisar, não repetir.
Cobrança por uso.
Casos de uso
Passo frágil de uma cadeia
Uma cadeia da Distribuidora Horizonte Verde depende de um serviço externo de frete que oscila no horário de pico. O passo frágil ganha nova tentativa e a cadeia deixa de quebrar por causa de um soluço de dez segundos.
E-mail de confirmação que não pode faltar
Thiago Barbosa Lima dispara e-mails de confirmação de matrícula nos cursos. Quando o envio falha por um instante, o retry reenvia sozinho — o aluno recebe o acesso mesmo assim, sem virar chamado de suporte.
Aviso de estoque que não pode se perder
A loja da Padaria Pão Dourado avisa o sistema de estoque a cada venda. Se o aviso falha por rede, a nova tentativa cobre o buraco e o estoque não sai do lugar por um erro passageiro.
Perguntas frequentes
Que tipo de falha vale a pena repetir?
As passageiras: rede que oscilou, serviço um instante fora do ar, um limite momentâneo. Erro de dado — CPF inválido, arquivo corrompido — não melhora com insistência; para esses, o certo é falhar logo e avisar.
As tentativas acontecem uma atrás da outra?
Não na lata. A espera cresce a cada rodada — alguns segundos, depois mais — para dar tempo de o outro lado se recuperar, em vez de martelar um serviço que já está sobrecarregado.
Como evito ficar tentando para sempre?
Você define o número máximo de tentativas. Atingido o teto, o retry para e o erro volta para o seu fluxo decidir — nada de bater eternamente numa porta que não vai abrir.
Quanto custa cada tentativa?
Uma tarefa que precisou de três rodadas custa três; uma que acertou de primeira, uma. Por isso o teto evita gasto à toa. Cobrança por uso.
Os dados da tarefa ficam guardados entre as tentativas?
O necessário para refazer a tentativa é processado com essa única finalidade e não vira arquivo nosso. O resultado volta para você quando dá certo; o histórico de longo prazo é do seu sistema.
Ferramentas relacionadas
Para desenvolvedores — acesso via API
Tudo nesta página está disponível via API. Esta seção é para equipes que querem integrar a ferramenta aos próprios sistemas; quem não precisa disso pode simplesmente usar a ferramenta acima.
Endpoint
Um POST autenticado cria a tarefa; o resultado chega por webhook ou por um link assinado. Esta capacidade está disponível pela API, não como ferramenta web interativa.
Chame do seu código
curl -X POST https://api.kit.forhosting.com/flow/retry \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"task_type":"dev.uuid"}'const res = await fetch("https://api.kit.forhosting.com/flow/retry", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"task_type": "dev.uuid"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/flow/retry",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"task_type": "dev.uuid"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/flow/retry", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"task_type":"dev.uuid"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"task_type":"dev.uuid"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/flow/retry", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Exemplo de requisição
{
"task_type": "dev.uuid"
}Exemplo de resposta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "flow.retry",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}A API é assíncrona: cada chamada devolve um task_id na hora. Se preferir polling, consulte o status a até 1 requisição por segundo.
Preço
Preço publicado, sem tokens nem créditos escondidos. Tarefa que falha não é cobrada.
Erros
| HTTP | Código | O que significa |
|---|---|---|
401 | unauthorized | Token ausente ou inválido. Confira o header Authorization. |
402 | insufficient_balance | Saldo insuficiente para esta tarefa. Faça uma recarga e tente de novo. |
404 | unknown_type | Esse tipo de tarefa não existe. Confira o campo type no catálogo. |
429 | rate_limited | Muitas requisições em pouco tempo. Espere um instante e tente de novo. |
Notas técnicas
Cada tentativa custa US$ 0,002.
Onde o retry se encaixa
Um webhook para um sistema que às vezes demora a responder, um passo de uma cadeia que depende de um serviço externo, uma entrega que não pode se perder por um soluço de rede — todos ganham resistência sem você reescrever a lógica.
Preço, e quando não vale insistir
Cada tentativa custa US$ 0,002 — a primeira e as repetições.
Casos de integração
Webhook para ERP que reinicia à noite
A TecnoSul Soluções Digitais envia webhooks para o ERP de um cliente que às vezes reinicia à noite. Com o retry, a entrega espera e tenta de novo sozinha — de manhã, tudo chegou, sem ninguém de plantão.
Perguntas técnicas
Dá para usar junto com o webhook e as cadeias?
Dá, e é onde ele mais serve: entregas de webhook e passos de cadeia que dependem de terceiros ganham resistência sem você reescrever nada. É a peça que faz o fluxo aguentar a internet real.