- Errori delle richieste API — la risposta HTTP a una chiamata API sincrona (autenticazione, fatturazione, richieste malformate, risorse inesistenti). Vedi Errori delle richieste API.
- Codici di fallimento delle prediction — la richiesta è stata accettata e messa in coda, ma la prediction stessa si è conclusa con
status: "failed". Il fallimento è descritto dall’oggettoerrordella prediction, che ottieni dagli endpoint di stato della prediction, dalle consegne webhook e dall’endpoint di risultato. Vedi Codici di fallimento delle prediction.
Codici di fallimento delle prediction
Una prediction fallita porta con sé un oggettoerror:
Le prediction fallite non vengono addebitate; i crediti riservati per la richiesta vengono rilasciati.
Una prediction che non è fallita porta con sé
error: null. Vedi la Nota di migrazione se hai integrato prima del 17 agosto 2026.
Dove ti arriva l’errore
Lo stesso oggettoerror viene pubblicato su ogni canale, così puoi leggerlo dove già guardi:
Leggere un fallimento dall’endpoint di risultato
Chiedere l’output di una prediction fallita restituisce un400 con il fallimento che l’ha causato, sotto il codice a livello di richiesta PREDICTION_FAILED:
error.codevalePREDICTION_FAILED, un errore di richiesta API che significa «la prediction di cui hai chiesto l’output non ne ha prodotto alcuno»;error.detailsè l’oggettoerrordella prediction stessa — identico a quanto/statusriporta per la stessa richiesta, così i due endpoint non possono mai essere in disaccordo sul motivo del fallimento. Fai i tuoi rami suerror.details.reasoneerror.details.retryable.
error.message ripete il messaggio della prediction, così anche un client che legge soltanto il messaggio di primo livello ottiene comunque qualcosa di utile.
Due timestamp, due significati. Il timestamp di primo livello indica quando è stata prodotta questa risposta HTTP; error.details.timestamp indica quando è fallita la prediction. Per una prediction che recuperi giorni dopo, i due distano giorni. Leggi quello interno ogni volta che intendi il fallimento.
Le librerie client ufficiali fanno questo lavoro per te: result() solleva un errore i cui code, reason e retryable sono quelli della prediction stessa, identici a quelli che subscribe() solleva per lo stesso fallimento.
Una prediction ancora in coda o in esecuzione, oppure annullata, continua a restituire lo stesso 400 generico di sempre.
Decidere se riprovare
Leggiretryable. Risponde esattamente a una domanda — inviare di nuovo questa identica richiesta porterà a un esito diverso? — ed è indipendente da code: lo stesso code può essere ritentabile in un fallimento e non in un altro.
retryable è opzionale. Quando è assente, ricadi sul default per code indicato nella tabella qui sotto. È il comportamento che Sunra aveva prima che questo campo esistesse, quindi ricadere sul default è sempre sicuro: semplicemente è meno preciso.
code
reason
reason nomina la causa specifica dietro a code. Usalo per metriche, instradamento e diagnosi del supporto; per la decisione se riprovare usa retryable.
Ogni reason pubblicata a oggi ha una sezione dedicata qui sotto, e la sua àncora è la reason stessa — #input_fetch_failed, #moderation_blocked e così via — così una segnalazione di errore può rimandare direttamente al suo significato.
input_validation_failed
code: invalid_input · retryable: false
La richiesta non ha superato la validazione di schema o di parametri di Sunra. Il message indica il campo che ha causato l’errore.
Cosa fare: correggi il campo indicato. La stessa richiesta continuerà a fallire.
provider_rejected_input
code: invalid_input · retryable: false
Il provider del modello ha rifiutato uno o più parametri di input. Quando il provider ci dice quali, il message lo riporta; alcuni provider comunicano soltanto che l’input non era accettabile, e in quel caso lo diciamo esattamente così invece di tirare a indovinare.
Cosa fare: confronta i tuoi parametri con lo schema del modello — un valore fuori intervallo, una combinazione non supportata, un rapporto d’aspetto o una durata che il modello non accetta.
input_fetch_failed
code: invalid_input · retryable: false o true
Non è stato possibile scaricare un file di input indicato tramite URL. È l’unica reason il cui retryable varia davvero, quindi leggi il campo invece di darlo per scontato:
false— l’host ci ha respinti: un4xx, un indirizzo da cui non ci è consentito scaricare, un redirect o un file oltre il limite di dimensione;true— l’host è risultato momentaneamente irraggiungibile: un5xx, un timeout o un errore DNS.
message riporta l’URL che hai inviato, così puoi capire quale input non è stato scaricato — privato della query string, in modo che le credenziali contenute in un presigned URL non ti vengano mai restituite:
retryable è false, verifica che l’URL sia raggiungibile pubblicamente e che un link presigned non sia scaduto. Quando è true, riprova.
moderation_blocked
code: unsafe_content · retryable: false
Bloccato dal sistema di content safety del provider del modello — sia il prompt e i media in ingresso, sia l’output generato in uscita.
Cosa fare: cambia il prompt o i media. Reinviare lo stesso contenuto verrà bloccato di nuovo.
provider_rate_limited
code: service_provider_error · retryable: true
Il provider del modello sta applicando rate limiting alle richieste.
Cosa fare: riprova con backoff, oppure instrada su un altro modello.
provider_unavailable
code: service_provider_error · retryable: true
Il provider del modello non è riuscito a servire la richiesta.
Cosa fare: riprova più tardi, oppure instrada su un altro modello.
provider_timeout
code: task_timeout · retryable: true
La prediction non è stata completata entro il tempo consentito.
Cosa fare: riprova — un momento di carico più basso, o una richiesta più piccola (durata più breve, risoluzione più bassa), aumenta le probabilità.
provider_account_error
code: internal_server_error · retryable: false
Il nostro account presso il provider del modello ha un problema — fatturazione, credenziali o una quota permanente. La colpa è nostra, non del tuo input.
Cosa fare: nulla dalla tua parte; riprovare non serve e riceviamo un alert in automatico. Instrada su un altro modello se ti serve subito quella capacità.
endpoint_misconfigured
code: internal_server_error · retryable: false
Questo endpoint del modello è mal configurato dalla nostra parte.
Cosa fare: nulla dalla tua parte; riprovare non serve e riceviamo un alert in automatico. Se è urgente contatta il supporto indicando il request_id.
queue_enqueue_failed
code: internal_server_error · retryable: true
Non è stato possibile mettere la prediction in coda.
Cosa fare: rinvia la richiesta.
reaped_stalled
code: internal_server_error · retryable: true
La prediction si è bloccata ed è stata terminata.
Cosa fare: rinvia la richiesta.
Valori sconosciuti
Siacode sia reason sono insiemi aperti. Nuovi valori vengono aggiunti man mano che classifichiamo altri fallimenti, senza annunci di breaking change. La tua integrazione non deve andare in crash, scartare l’errore o rifiutare il payload quando incontra un valore che non riconosce.
reasonsconosciuto — trattalo come sereasonfosse assente e decidi in base aretryable(o al default percode). Conserva il valore grezzo nei log: è il modo più rapido per far identificare il fallimento al supporto.codesconosciuto — trattalo comeinternal_server_error. C’è un valore sentinella che vale la pena conoscere per nome:unknown_error_code, che Sunra emette quando una prediction è fallita ma non è stato possibile recuperarne alcuna classificazione.
Nota di migrazione: error è null quando non c’è alcun errore
In vigore dal 17 agosto 2026. L’oggettoerror ha un’unica rappresentazione su ogni canale. Tre differenze tra loro sono sparite:
errorvalenullquando la prediction non è fallita.GET /v1/predictions/{prediction_id}rispondeva con un oggetto vuoto —"error": {}— su ogni prediction riuscita, in coda o annullata. Ora risponde"error": null, che è ciò che l’endpoint di stato della coda faceva già. Se verifichi che sia vuoto (Object.keys(response.error).length === 0), sostituisci quel controllo con un controllo su null (response.error === null).- Un fallimento porta sempre con sé un
codee unmessagenon vuoti. Dove un fallimento ha registrato qualcosa che non siamo in grado di classificare, ora ricevi il valore sentinellaunknown_error_codee un messaggio generico, invece di un campo mancante, vuoto o che non è una stringa. - I fallimenti registrati come testo semplice ti arrivano come testo. Poche prediction dell’aprile 2026 hanno memorizzato il proprio errore come stringa nuda.
GET /v1/predictions/{prediction_id}la scartava e l’endpoint di stato della coda la sostituiva con il messaggio sentinella; ora entrambi la pubblicano comemessagesottocode: "unknown_error_code".
error era già presente su ognuna di queste risposte, ed è cambiato soltanto il suo valore. Le consegne webhook non sono state toccate — erano già la forma su cui gli altri canali sono convergiti — e error resta assente da una consegna succeeded invece di essere inviato come null.
Finestra di compatibilità. Non c’è alcun periodo di doppia emissione: da quella data l’API ha smesso di produrre "error": {}. Se riesegui o rielabori payload catturati prima di allora, tratta null e {} come la stessa cosa finché quei dati memorizzati non saranno scaduti.
Modifica in arrivo: alcuni fallimenti riceveranno un code più specifico
Oggi una quota rilevante dei fallimenti viene segnalata come service_provider_error, inclusi molti che non sono né transitori né colpa del provider. Man mano che classifichiamo i provider uno alla volta, quei fallimenti passano al code che li descrive davvero:
- un provider che rifiuta in modo deterministico il tuo input diventa
invalid_input(primaservice_provider_error); - un problema lato Sunra, come un endpoint mal configurato o il nostro account presso il provider, diventa
internal_server_error(primaservice_provider_error); - un file di input che non siamo riusciti a scaricare diventa
invalid_input(primainternal_server_error).
code: i cinque valori qui sopra restano l’insieme completo dei codici classificati. Ciò che cambia è quale di essi viene assegnato a un dato fallimento, e cambia gradualmente, provider per provider. Se il tuo codice si dirama su code, questo è il momento giusto per spostare quella logica su retryable e reason, che descrivono il fallimento in modo diretto e non sono toccati da questa riclassificazione.