Un 200 OK non significa che il lavoro è stato fatto. Significa che il server ha ricevuto la richiesta e ha risposto senza crashare. Sono due cose diverse, e confonderle è il modo più veloce per avere un’automazione che gira regolare mentre produce risultati sbagliati.
Gli errori nelle automazioni API non suonano allarmi. Non mandano email. Non bloccano il flusso. Si nascondono nel body della risposta, sotto campi come tasks_error, failed_count o status: failed, mentre il tuo scenario su Make o n8n vede il 200 e passa alla fase successiva. Il problema non è il tool che usi. È che stai controllando la cosa sbagliata. Questo articolo spiega il meccanismo, mostra un caso concreto, e ti dà le guardie da mettere prima di andare in produzione.
Come funziona davvero un 200 OK nelle API
Il codice HTTP descrive il trasporto, non il risultato. Una risposta 200 dice che la connessione è avvenuta, che il server ha processato la richiesta nel senso tecnico del termine, e che ti ha mandato qualcosa indietro. Non dice niente su cosa c’è dentro quel qualcosa.
Molte API — soprattutto quelle che gestiscono operazioni in batch o task asincroni — usano il 200 come contenitore. Dentro il body mettono uno stato per ogni operazione singola. Se hai mandato dieci task, potresti ricevere un 200 con sette successi e tre fallimenti. Il codice HTTP è 200. Il lavoro fatto è il 70%.
Il silenzio non è salute: è il sintomo. Un’automazione senza guardie esegue sbagliato con la stessa sicurezza con cui esegue giusto.
Questo non è un bug delle API. È il design intenzionale di molti servizi che vogliono evitare di restituire un 500 per un errore parziale. Il problema è che la maggior parte dei flow di automazione si fermano al codice HTTP e non vanno a guardare dentro.
Il caso concreto: 14 chiamate, 11 eseguite, nessun allarme
Prendi un flusso con 14 chiamate API in sequenza. Alla undicesima, il saldo del servizio si esaurisce. La API risponde 402 Payment Required — errore chiaro, codice esplicito. Ma le chiamate precedenti — quelle andate a buon fine nel senso HTTP — contenevano task_error nel body. Il flusso le aveva considerate tutte OK. Metà del lavoro mancava, nessun log segnalava niente, nessuna notifica era partita.
Il 402 alla fine era quasi un regalo: almeno interrompeva. Il danno reale erano i task falliti silenziosi nelle risposte precedenti, già catalogati come successi dal sistema.
Perché gli errori API nelle automazioni sono così difficili da vedere
I tool di automazione come Make gestiscono gli errori HTTP in modo nativo: un 4xx o 5xx blocca lo scenario e puoi configurare un error handler. Ma se la risposta è 200, lo scenario non ha niente da intercettare. Passa avanti. Salva il body. Considera l’operazione completata.
Il risultato è che i report nativi dei tool di automazione mostrano run verdi. Zero errori a livello di scenario. Eppure nel CRM mancano contatti, nel foglio mancano righe, nel sistema downstream mancano dati. Se non vai a guardare l’output reale, non lo sai.
I report nativi di Make ti dicono se uno scenario ha girato. Non ti dicono se ha prodotto quello che doveva produrre.
Il pattern più comune: le API batch
Le API che accettano array di oggetti sono le più esposte. Mandi una lista, ricevi un 200 con un array di risultati. Ogni elemento dell’array ha il suo stato. Se non iteri su quell’array e non verifichi ogni stato, stai ignorando sistematicamente i fallimenti parziali.
Lo stesso meccanismo vale per le API asincrone che restituiscono un job_id: il 200 dice «ho accettato il job», non «il job è completato». Per sapere se ha funzionato devi fare una seconda chiamata di polling sullo stato. Chi costruisce il flow in fretta spesso non la fa.
Come costruire le guardie contro gli errori silenziosi nelle API
La regola è una sola: non fidarti mai del codice HTTP come indicatore di successo. Verifica sempre il body.
1. Mappa la struttura della risposta prima di costruire il flow
Prima di collegare una API a un’automazione, leggi la documentazione ufficiale e fai una chiamata di test con un caso di fallimento intenzionale. Guarda come la risposta cambia. Cerca campi come status, error, failed, errors, tasks_error. Capire la struttura della risposta prima di costruire il flow ti fa risparmiare ore di debug dopo.
La documentazione API di Make e quella dei singoli servizi che integri sono il punto di partenza obbligatorio, non un optional da leggere «se hai problemi».
2. Aggiungi un modulo di validazione dopo ogni chiamata critica
In Make, dopo ogni HTTP Request su un’operazione critica, aggiungi un Router o un Filter che legge il campo di stato nel body. Se il campo non corrisponde al valore atteso, il flow si ferma e va su un percorso di errore esplicito. Non aspettare che il problema emerga a valle: intercettalo subito, nel punto in cui si verifica.
Per le risposte batch, itera sull’array dei risultati e filtra gli elementi con stato fallito. Mandali su una coda separata o su un foglio di log. Almeno sai cosa è andato storto e puoi intervenire.
3. Tratta il saldo API come un guasto monitorabile
Un 402 Payment Required non è un errore di codice: è un guasto infrastrutturale prevedibile. Il saldo si esaurisce. Il piano si riempie. Il rate limit scade. Queste cose hanno segnali anticipatori — endpoint di stato, header di risposta, dashboard con soglie configurabili.
Metti in piedi un check periodico sul saldo disponibile dei servizi critici. Su n8n puoi farlo con un flow schedulato che chiama l’endpoint di status e manda una notifica se il valore scende sotto una soglia. Cinque minuti per costruire questo check ti evitano di scoprire il problema a metà di un run da 500 contatti.
Se stai costruendo automazioni su più tool, il concetto si applica ovunque. L’articolo su n8n copre come strutturare i flussi di errore in modo esplicito.
4. Costruisci log attivi, non passivi
Un log passivo registra quello che succede. Un log attivo ti avvisa quando quello che succede non corrisponde a quello che dovrebbe succedere. La differenza pratica: il log passivo ti mostra che il flow è girato; quello attivo ti dice che il 15% dei task nel body erano failed e nessuno li ha rilavorati.
Il modo più semplice: dopo ogni batch di chiamate API, scrivi su un foglio il numero di task ricevuti, il numero di successi e il numero di fallimenti. Se fallimenti > 0, parte una notifica. Non serve un sistema sofisticato. Serve una guardia.
Errori API nelle automazioni: cosa cambia nel design del sistema
Capire che 200 OK non significa «fatto» cambia come progetti un’automazione da zero. Non è solo una questione di aggiungere controlli a posteriori. È una questione di architettura.
Un flow ben progettato separa la fase di chiamata dalla fase di verifica. Chiami la API, salvi il body grezzo, poi hai un secondo momento in cui analizzi il body e decidi cosa fare con ogni singolo risultato. Questo ti permette di rieseguire solo i task falliti senza ridare tutto dall’inizio, di avere un log granulare di cosa è andato storto, e di rendere il sistema idempotente — puoi rieseguirlo senza duplicare i successi.
Chi scala senza assumere non può permettersi macchine che producono errori invisibili. L’articolo su come automatizzare un’agenzia parte esattamente da questo: prima si progetta il processo, poi si sceglie il tool. Le guardie non si aggiungono dopo. Si disegnano prima.
Un’automazione senza guardie non è finita. È in attesa di produrre un errore silenzioso.
Come controllare gli errori API su Make.com in pratica
Su Make, il punto di intervento è il modulo che riceve la risposta HTTP. Dopo quel modulo, prima di qualsiasi operazione downstream, inserisci un Set Variable che estrae il campo di stato dal body. Poi un Filter: se il campo non è uguale al valore atteso, il percorso principale si interrompe e parte un percorso di errore.
Per le risposte array, usa un Iterator seguito da un Filter per isolare i task con stato fallito. Mandali su un Google Sheet dedicato agli errori, con timestamp, payload originale e messaggio di errore. Questo foglio è la tua coda di retry manuale o automatica.
Se lavori con Make.com e vuoi costruire questa struttura partendo da template già impostati per la gestione degli errori, puoi partire da qui.
Per i flow asincroni con job_id, aggiungi un secondo scenario schedulato che fa polling sullo stato ogni N minuti fino a completamento o timeout. Non aspettare che qualcuno ti dica che il job non è finito: costruisci tu il meccanismo di verifica.
Gli errori nelle API nelle automazioni non emergono da soli. Li vai a cercare, o ti trovano loro nel momento sbagliato.
Domande frequenti
Perché un’API restituisce 200 anche quando qualcosa è andato storto?
Il codice HTTP 200 descrive il trasporto, non il risultato dell’operazione. Molte API usano il 200 per confermare che la richiesta è stata ricevuta e processata, poi comunicano il successo o il fallimento delle singole operazioni dentro il body della risposta, spesso in campi come status o errors.
Come faccio a sapere se una API usa errori nel body invece dei codici HTTP?
Leggi la documentazione ufficiale del servizio e fai una chiamata di test con parametri volutamente sbagliati. Osserva la risposta: se il codice è 200 ma il body contiene un campo error o status diverso da success, quella API usa gli errori nel body. Trattala di conseguenza in ogni flow che costruisci.
Cosa succede se non aggiungo guardie sugli errori silenziosi in un’automazione?
Il flow gira regolare. I log dei tool mostrano run verdi. Nel sistema downstream mancano dati, contatti, righe, operazioni. Lo scopri quando il problema diventa visibile a qualcuno — un cliente che non riceve qualcosa, un report che non torna. A quel punto il danno è già fatto.
Vale la pena costruire queste guardie anche per flow piccoli?
Sì. Un flow piccolo che gira cento volte al giorno produce cento opportunità di errore silenzioso. La dimensione del flow non cambia la probabilità che la API restituisca un task fallito dentro un 200. Cambia solo la scala del problema quando lo scopri tardi.
Trasparenza: in questo articolo c’è un link di affiliazione. Se ti iscrivi da lì io ricevo una commissione, per te non cambia niente. Linko solo strumenti che uso in produzione.
