Reintenta tareas fallidas
Toda integración termina topándose con un servicio que responde tarde, un DNS que titubea o un error 503 que se resuelve solo en cuestión de segundos. La API de Política de Reintentos permite adjuntar backoff exponencial y una cola de fallos a cualquier paso de un flujo con una sola llamada, para que esas fallas pasajeras dejen de convertirse en alertas a las tres de la mañana. Se configura una vez y cada tarea del flujo hereda la misma disciplina.
El problema: las fallas temporales no deberían ser su problema
La mayoría de las fallas dentro de un flujo de automatización no son fallas reales, sino un servicio que apenas está arrancando, un límite de tasa que se está reiniciando o un balanceador de carga en medio de un despliegue. Los equipos que programan su propia lógica de reintentos terminan con reglas inconsistentes repartidas en distintos scripts: un proceso reintenta tres veces, otro reintenta indefinidamente y un tercero simplemente falla de forma ruidosa. flow.retry centraliza esa decisión para que cada paso del flujo siga la misma curva de espera, y los equipos dejan de depurar lógica de reintentos en lugar del problema real del negocio.
Cómo funciona
Se envía un POST a /flow/retry con el identificador del flujo o del paso y una política: retraso base, multiplicador, número máximo de intentos y una bandera opcional de aleatorización (jitter) para evitar que muchas tareas reintenten exactamente al mismo tiempo. La llamada es asíncrona y devuelve un task_id de inmediato; la política queda aplicada y se confirma mediante webhook firmado o un enlace firmado válido por 24 horas. Una vez configurada, cualquier tarea correspondiente que falle se vuelve a encolar automáticamente con retrasos que crecen de forma exponencial —por ejemplo 1s, 2s, 4s, 8s— hasta que tenga éxito o agote los intentos configurados.
Dónde entra la cola de fallos
El backoff exponencial resuelve el caso común, pero algunas fallas son permanentes: un payload malformado, una credencial revocada, un destino que jamás va a responder. Después del último intento, la tarea cae en una cola de fallos en lugar de desaparecer o quedar reintentando para siempre. El resultado es un error claro y detallado en vez de una pérdida silenciosa, y usted puede inspeccionar, reprocesar o descartar esas tareas sin tocar el resto del flujo.
Una breve nota sobre el patrón
El backoff exponencial proviene del algoritmo original de detección de colisiones de Ethernet, y el concepto de cola de fallos nace de los sistemas de mensajería empresarial diseñados para que un mensaje defectuoso no bloquee toda una cola. Ambas ideas existen por la misma razón: los sistemas distribuidos fallan de forma pequeña y recuperable con mucha más frecuencia que de forma catastrófica, y tratar cada falla como si fuera igual desperdicia cómputo y atención.
Cómo encaja en la automatización
Como la política se define por flujo o por paso, se puede ser agresivo en llamadas baratas e idempotentes y conservador en cualquier cosa que modifique estado o tenga costo aguas abajo. Se integra de forma limpia con el resto del motor de flujos: los reintentos ocurren dentro del mismo grafo de ejecución, las notificaciones por webhook se disparan tanto en el éxito eventual como en el envío final a la cola de fallos, y no hace falta un cron job ni un proceso vigilante aparte.
Qué puede hacer con ella
Webhooks inestables de terceros
Una API de un socio devuelve ocasionalmente un 502 durante sus propios despliegues; en vez de fallar el flujo, el paso reintenta con backoff y normalmente tiene éxito en segundos.
Llamadas de enriquecimiento con límite de tasa
Un paso de enriquecimiento de datos que a veces choca con un límite de tasa espera automáticamente en lugar de insistir sobre el mismo endpoint y quedar bloqueado temporalmente.
Importaciones masivas con un registro defectuoso
De 10,000 filas, tres tienen datos malformados y nunca tendrán éxito; tras los reintentos caen en la cola de fallos para que las otras 9,997 no queden detenidas.
Confirmación de un webhook de pago
Una llamada de confirmación hacia un libro contable posterior falla una vez por un arranque en frío; el backoff exponencial la reintenta antes de escalar, evitando una alerta de falla falsa.
Preguntas frecuentes
¿Qué configura exactamente la API de reintentos automáticos?
Define una política de reintentos por flujo o por paso —retraso base, multiplicador de espera, número máximo de intentos y jitter opcional— que se aplica automáticamente cada vez que ese paso falla.
¿Es gratis usar flow.retry?
No hay capa gratuita: las capas gratis se abusan y ralentizan a todos. El acceso funciona con un saldo prepago de ForHosting KIT: se recarga desde $10.00 (no caduca) y cada solicitud se cobra a su precio publicado, así que una llamada sin saldo devuelve HTTP 402. Sin suscripción, sin tokens ni créditos inventados, y una tarea fallida no se cobra.
¿Se cobra si un intento de reintento falla?
No. Una tarea fallida nunca se cobra. El sistema realiza hasta 3 reintentos internos y solo devuelve un error final claro si todos los intentos fallan.
¿Qué pasa cuando se agotan los reintentos máximos?
La tarea pasa a una cola de fallos en lugar de perderse en silencio, así que se puede inspeccionar, reprocesar o descartar sin afectar el resto del flujo.
¿Cómo obtengo el resultado de una llamada a POST /flow/retry?
El endpoint es asíncrono y devuelve un task_id de inmediato; el resultado llega por webhook firmado, que es lo recomendado, o mediante un enlace firmado válido por 24 horas.
¿Puedo usar políticas de reintento distintas para pasos distintos del mismo flujo?
Sí, las políticas se configuran por flujo o por paso, de modo que puede ser agresivo en llamadas baratas e idempotentes y conservador en las que modifican estado.
¿Qué es el jitter y por qué activarlo?
El jitter aleatoriza levemente los tiempos de espera entre reintentos para que muchas tareas que fallan al mismo tiempo no reintenten todas en el mismo instante y saturen de nuevo el servicio destino.
¿Esto reemplaza mi propio monitoreo de errores?
No, lo complementa: los errores temporales se absorben automáticamente, mientras que las tareas enviadas a la cola de fallos siguen mostrando un error claro que puede enrutar hacia su propio monitoreo.
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, y pronto desde nuestra app, el email y Telegram.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/flow/retry \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"input":"…"}'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({
"input": "…"
})
});
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={
"input": "…"
},
)
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" => '{"input":"…"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"input":"…"}`)
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)Ejemplo de solicitud
{
"input": "…"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "flow.retry",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |