Skip to main content
Gli errori compaiono in due punti distinti e usano due vocabolari diversi:
  • 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’oggetto error della 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 oggetto error:
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 oggetto error 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 un 400 con il fallimento che l’ha causato, sotto il codice a livello di richiesta PREDICTION_FAILED:
Due codici, su due livelli, e non appartengono allo stesso vocabolario:
  • error.code vale PREDICTION_FAILED, un errore di richiesta API che significa «la prediction di cui hai chiesto l’output non ne ha prodotto alcuno»;
  • error.details è l’oggetto error della prediction stessa — identico a quanto /status riporta per la stessa richiesta, così i due endpoint non possono mai essere in disaccordo sul motivo del fallimento. Fai i tuoi rami su error.details.reason e error.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

Leggi retryable. 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: un 4xx, un indirizzo da cui non ci è consentito scaricare, un redirect o un file oltre il limite di dimensione;
  • true — l’host è risultato momentaneamente irraggiungibile: un 5xx, un timeout o un errore DNS.
Il 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:
Cosa fare: quando 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

Sia code 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.
  • reason sconosciuto — trattalo come se reason fosse assente e decidi in base a retryable (o al default per code). Conserva il valore grezzo nei log: è il modo più rapido per far identificare il fallimento al supporto.
  • code sconosciuto — trattalo come internal_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’oggetto error ha un’unica rappresentazione su ogni canale. Tre differenze tra loro sono sparite:
  • error vale null quando 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 code e un message non vuoti. Dove un fallimento ha registrato qualcosa che non siamo in grado di classificare, ora ricevi il valore sentinella unknown_error_code e 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 come message sotto code: "unknown_error_code".
Non è stato rimosso nulla e non è comparso alcun campo nuovo: 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 (prima service_provider_error);
  • un problema lato Sunra, come un endpoint mal configurato o il nostro account presso il provider, diventa internal_server_error (prima service_provider_error);
  • un file di input che non siamo riusciti a scaricare diventa invalid_input (prima internal_server_error).
Nessun codice viene rinominato o rimosso e non viene introdotto alcun nuovo valore di 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.

Errori delle richieste API