Se qualcosa fallisce, riprova da solo
Un’operazione fallita viene ritentata dopo attese crescenti, per esempio 1, 2, 4 e 8 secondi, finché riesce o esaurisce i tentativi. Se 3 righe su 10.000 non possono mai riuscire, restano da parte e le altre 9.997 proseguono.
flow.retry fa ripetere automaticamente un’operazione fallita, un numero di volte che definisci tu, prima di segnalarla come definitivamente non riuscita — utile per errori temporanei come una connessione instabile o un servizio esterno momentaneamente occupato altrove, fuori dal tuo controllo.
Riprovare con attese crescenti
Molti errori in un’automazione non sono veri errori: un servizio che si sta avviando, un limite di richieste che si azzera, un aggiornamento in corso. Per questo, quando un’operazione fallisce, viene rimessa in coda con attese che crescono a ogni tentativo, per esempio 1, 2, 4 e 8 secondi, finché riesce o esaurisce il numero di tentativi che Lei ha stabilito. Impostata una volta, la stessa regola vale per ogni passaggio del flusso, così non ci sono procedure diverse che riprovano tre volte, all’infinito o mai. Un’opzione aggiunge una piccola variazione alle attese, perché molte operazioni non riprovino tutte nello stesso istante.
Quando arrendersi e gli errori tipici
Alcuni errori sono permanenti: un dato malformato, un’autorizzazione revocata, una destinazione che non risponderà mai. Dopo l’ultimo tentativo l’operazione finisce in una coda dei falliti invece di sparire o girare per sempre, con un errore chiaro che può esaminare, rilanciare o scartare senza toccare il resto. Se 3 righe su 10.000 sono sbagliate, le altre 9.997 proseguono. L’errore tipico è usare la stessa insistenza ovunque: conviene essere generosi con i tentativi sulle operazioni semplici e ripetibili, e prudenti su quelle che modificano dati o generano costi.
Non tutti gli errori sono definitivi
Un tentativo che fallisce non sempre significa che l’operazione è impossibile: a volte è solo un servizio momentaneamente occupato, una connessione instabile, un timeout passeggero. Trattare questi casi come un fallimento definitivo butta via lavoro che sarebbe riuscito al secondo tentativo. flow.retry riprova automaticamente prima di dichiarare la resa, risparmiando l’intervento manuale per i casi in cui serve davvero un occhio umano.
Come si configura il ritentativo
Indichi quante volte riprovare e quanto tempo aspettare tra un tentativo e l’altro — un’attesa fissa, oppure crescente a ogni tentativo per non insistere subito su un servizio già in difficoltà. Se anche l’ultimo tentativo fallisce, l’operazione viene segnalata come fallita in modo definitivo, con lo storico di tutti i tentativi effettuati e il motivo di ciascun errore, così sai esattamente cosa è successo.
Casi d'uso
Invio email che assorbe un errore temporaneo
Consulenza IT Marchetti S.r.l. imposta tre tentativi automatici per l’invio delle email di fatturazione, così un problema momentaneo del server di posta non fa saltare l’avviso ai clienti.
Passaggio di una catena che si riprende da solo
In una catena che legge un documento e lo elabora, Web Agency Nuvola S.r.l. ha collegato il ritentativo al passaggio di lettura, il più esposto a errori temporanei di connessione con il servizio esterno del cliente.
Domande frequenti
Quanti tentativi vengono fatti prima di dichiarare l’operazione definitivamente fallita?
Lo decidi tu al momento della configurazione: puoi impostare da uno a più tentativi, con l’intervallo di attesa che preferisci tra uno e l’altro.
L’attesa tra un tentativo e l’altro è sempre la stessa?
Puoi scegliere un’attesa fissa oppure crescente a ogni tentativo, così da non insistere subito su un servizio che sta già avendo problemi, dandogli il tempo di riprendersi.
Pago per ogni tentativo o solo per quello riuscito?
Se l’operazione riesce al primo colpo, non ci sono tentativi aggiuntivi e nessun costo di ritentativo.
Posso vedere lo storico dei tentativi fatti su un’operazione?
Sì, ogni tentativo viene registrato con il proprio esito, così puoi capire se un errore era isolato o se si ripete sistematicamente e merita un’indagine più approfondita.
Ha senso su qualsiasi tipo di operazione o solo su alcune?
Per un errore dovuto a dati sbagliati in partenza, riprovare non cambia il risultato: in quel caso il problema va corretto a monte.
Strumenti correlati
Per sviluppatori — accesso via API
Tutto quello che vedi in questa pagina è disponibile anche via API. Questa sezione è per i team che vogliono integrarlo nei propri sistemi; chi non ne ha bisogno può semplicemente usare lo strumento qui sopra.
Endpoint
Un POST autenticato crea l'attività; il risultato arriva via webhook o con un link firmato. Questa capacità è disponibile via API, non come strumento web interattivo.
Chiamala dal tuo stack
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)Esempio di richiesta
{
"task_type": "dev.uuid"
}Esempio di risposta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "flow.retry",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L'API è asincrona: ricevi subito un task_id e puoi fare polling fino a 1 richiesta al secondo.
Prezzi
Prezzo pubblicato, senza token né crediti. Se l'attività fallisce, non paghi.
Errori
| HTTP | Codice | Significato |
|---|---|---|
401 | unauthorized | Chiave API mancante o non valida: controlla l'header Authorization. |
402 | insufficient_balance | Credito esaurito: ricarica per continuare a eseguire attività. |
404 | unknown_type | Tipo di attività sconosciuto: controlla il campo type della richiesta. |
429 | rate_limited | Troppe richieste in poco tempo: rallenta e riprova tra qualche secondo. |
Note tecniche
Dove si combina meglio
Il ritentativo automatico rende più solide le catene di più passaggi e i webhook verso sistemi esterni: se un passaggio della catena fallisce per un motivo temporaneo, o se il tuo sistema non risponde subito a un webhook, il ritentativo evita di perdere l’intera esecuzione per un intoppo passeggero, senza bisogno di rilanciare tutto a mano da capo, sorvegliando l’operazione in prima persona.
Prezzo per ogni tentativo effettivamente fatto
Se un’operazione riesce al primo tentativo, non c’è alcun costo di ritentativo aggiuntivo: paghi solo per i tentativi in più che servono davvero a recuperare un errore temporaneo, non per quelli mai avvenuti né per la sola configurazione impostata in partenza dal tuo flusso di lavoro. Paghi $0.002 per ogni tentativo di ritentativo effettivamente eseguito, non per la sola configurazione.
Casi di integrazione
Webhook che riprova se il sistema non risponde
Rossi & Figli S.r.l. collega il ritentativo automatico ai webhook verso il proprio gestionale: se il sistema è momentaneamente offline per un aggiornamento, l’evento non va perso, ma riprovato più volte finché non viene ricevuto.