Conservazione e distruzione

La conservazione ha due livelli. Il limite massimo della piattaforma è un impegno pubblico, non un parametro interno da regolare. Entro quel limite, puoi impostare periodi più brevi e distruggere il contenuto di una singola attività quando vuoi.

Il rapporto tra i due livelli si riassume in una frase: puoi soltanto abbreviare il periodo; nessuna tua impostazione può aumentare il limite massimo.

Per quanto tempo conserviamo i dati (limiti della piattaforma)

Puoi abbreviare i periodi delle prime quattro righe con i quattro intervalli descritti sotto: risultati generati, inclusi file e contenuto della risposta, contenuti multimediali dei cortometraggi, testo dei prompt e file caricati.

I contenuti dei cortometraggi hanno una finestra più lunga perché un film in Spicy Studio viene costruito nell'arco di giorni o settimane, e una scena creata nella prima settimana deve essere ancora disponibile quando si esporta il film completo. Questo vale soltanto per le attività avviate all'interno di un progetto di cortometraggio nello Studio; lo stesso modello chiamato tramite API, SDK o Playground mantiene il limite di 14 giorni, mentre il testo dei prompt mantiene il limite di 30 giorni in entrambi i casi. Gli altri periodi rispondono a obblighi della piattaforma o previsti dalla legge e non cambiano con le tue impostazioni.

Quattro intervalli, impostati separatamente

Rispondono a quattro domande diverse, non a una sola domanda con quattro impostazioni. I nomi qui sotto sono quelli mostrati nella console:

Impostali in Conservazione nella pagina Protezione dei dati della console. Quando un'attività viene accettata, ricava i propri tempi di scadenza dei risultati e dei prompt da queste impostazioni e dall'header descritto sotto; puoi leggerli in retention dentro recordInfo.

«Elimina al termine dell'attività» significa che un file caricato viene eliminato quando tutte le attività che lo utilizzano hanno raggiunto uno stato finale (succeeded / failed / canceled / expired), normalmente entro un minuto. Non viene eliminato alla creazione dell'attività, perché un nuovo tentativo ne ha bisogno. Considera prima la conseguenza: per elaborare di nuovo la stessa immagine devi ricaricarla, e un nuovo tentativo fallirà.

Effetti di una modifica sui dati già presenti

Cambiare un intervallo non è semplicemente un interruttore «da ora in poi». Alcune modifiche si applicano anche alle attività che hai già eseguito; altre no. Oggi funziona così:

Alcune modifiche si applicano retroattivamente perché i tempi di scadenza di ogni attività vengono fissati all'accettazione, ma un secondo processo di pulizia lavora per giorni interi. Legge l'impostazione Testo dei prompt, la arrotonda per eccesso a 1, 7 o 30 giorni e la applica a tutte le attività concluse dell'account; quando svuota un'attività, rimuove insieme testo dei prompt e risultati.

La stessa pagina ha una seconda scheda, Conservazione del contenuto delle attività, che controlla direttamente quel processo basato sui giorni:

• Scegliere 1 giorno o 7 giorni elimina testo dei prompt, risultati e file generati di tutte le attività concluse da più di quel periodo, continuando a farlo per ogni attività quando raggiunge quella età.
• Attivare Cancella il contenuto poco dopo il completamento li elimina per ogni attività conclusa, incluse quelle eseguite prima dell'attivazione, circa un'ora dopo il completamento di ciascuna.
• Le due schede condividono le impostazioni: salvare in una modifica ciò che mostra l'altra.

Impostazione per singola richiesta: X-Spicy-Retention

Se non vuoi cambiare l'impostazione dell'account e desideri soltanto che questa generazione scompaia prima, invia l'header alla creazione dell'attività. Il valore è un numero intero di secondi e si applica ai file e al prompt di questa attività:

curl -X POST https://api.spicyapi.ai/api/v1/jobs/createTask \
  -H "Authorization: Bearer $SPICY_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $SPICY_IDEMPOTENCY_KEY" \
  -H "X-Spicy-Retention: 3600" \
  --data "$TASK_PAYLOAD"

• Solo periodi più brevi. Il valore effettivo è min(header, account setting, platform cap). Quando un amministratore imposta l'account a un'ora, una singola richiesta non può ottenere di nuovo 14 giorni: altrimenti l'impostazione dell'account sarebbe un suggerimento, non un'impostazione.
• 0 è valido e significa «elimina i file non appena l'attività raggiunge uno stato terminale».
• Un valore non valido non fa fallire la richiesta. Un numero negativo viene limitato a 0; un valore oltre il limite massimo viene ridotto al limite; un valore che non è un intero decimale viene ignorato, applicando quindi l'impostazione dell'account. Il valore effettivamente applicato viene sempre riportato in retention dentro recordInfo. Un header che chiede soltanto una conservazione più prudente non dovrebbe mai interrompere una generazione.
• Quali endpoint lo leggono. Lo leggono sia jobs/createTask sia jobs/stream. jobs/retry eredita il valore effettivo dell'attività sorgente e ignora l'header: un retry è un secondo tentativo della stessa operazione, e consentirgli un periodo diverso darebbe due scadenze diverse a una famiglia di attività. jobs/quote non lo legge, perché non crea attività.

recordInfo restituisce retention per ogni attività; la risposta di createTask non lo include, quindi leggilo dopo la creazione:

{
  "retention": {
    "outputsExpireAt": "2026-09-13T12:00:00Z",
    "promptsExpireAt": "2026-09-13T12:00:00Z",
    "source": "header"
  }
}

source indica quale livello ha determinato il valore: header (questa richiesta), account (impostazione dell'account) o platform (limite massimo). Se invii l'header ma ottieni comunque account, l'impostazione dell'account era già più breve di quanto richiesto.

Prima che l'attività termini, outputsExpireAt è calcolato dall'accettazione; quando l'attività raggiunge uno stato terminale, viene ricalcolato dal momento di completamento, usando la stessa finestra. Può quindi spostarsi soltanto più avanti, mai prima. Affidati alle date e ore della risposta invece di ricalcolarle: il risultato dell'applicazione dei tre limiti non è sempre quello atteso. A parte una distruzione richiesta da te, l'unico meccanismo che può rimuovere i contenuti prima di questi tempi è un'impostazione retroattiva dell'account, come descritto sopra.

Distruggere i contenuti su richiesta: POST /jobs/purge

Se non vuoi aspettare la scadenza:

• Nella console, apri l'attività nei Log e scegli Distruggi gli output: è la stessa operazione dell'endpoint seguente.
• Rimuovi dalla cronologia, sulla stessa attività, svuota anch'esso prompt e risultato e accoda i file per la cancellazione, nascondendo inoltre l'attività dai tuoi log. È disponibile dopo la conclusione dell'attività e il regolamento della fatturazione.

Nessuna delle due azioni cambia l'addebito e nessuna annulla un'attività. Da codice:

curl -X POST https://api.spicyapi.ai/api/v1/jobs/purge \
  -H "Authorization: Bearer $SPICY_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{"taskId": "job_01k..."}'

La risposta:

{
  "taskId": "job_01k...",
  "contentState": "purged",
  "purgedAt": "2026-09-13T12:00:00Z",
  "contentRemovedBy": "user",
  "billingRetained": true,
  "mediaDeletionPending": true
}

Alcune regole:

• Solo attività terminali (succeeded / failed / canceled / expired). Aspetta la fine di un'attività in corso: i file non sono ancora arrivati e una cancellazione parziale è peggio di nessuna cancellazione. Una generazione non può essere annullata dopo l'accettazione, quindi non esiste un percorso «prima annulla, poi distruggi».
• L'operazione è idempotente e non richiede Idempotency-Key. L'endpoint è idempotente in base a taskId: richiamarlo su un'attività già distrutta restituisce comunque 200, e purgedAt indica il momento della prima distruzione, non quello della chiamata corrente. Riprovare dopo un timeout è sicuro.
• La risposta significa «programmata», non «già eliminata». Quando mediaDeletionPending è true, contentState è già purged, ma il processo in background non ha ancora completato la rimozione degli oggetti; normalmente termina entro un minuto. Una cancellazione sincrona permetterebbe a un singolo oggetto problematico di bloccare tutta la richiesta, proprio quando hai bisogno di una risposta chiara.
• Una risposta ancora present significa che questa chiamata non ha rimosso nulla, per esempio perché l'attività è soggetta a un obbligo di conservazione. Puoi riprovare più tardi; la motivazione specifica non viene deliberatamente divulgata.
• billingRetained è sempre true. Può sembrare ridondante, ma è presente perché è il punto che più facilmente viene frainteso da chi chiama questo endpoint: vedi sotto.

contentState: presenza dei contenuti e autore della rimozione

I dettagli dell'attività includono contentState, con tre valori:

Gli ultimi due includono purgedAt, cioè il momento della rimozione, e contentRemovedBy: system per il processo di pulizia e user per te.

Mostrare purged come «scaduto» è sbagliato per lo stesso motivo, al contrario: uno è un pulsante premuto dall'utente, l'altro è la nostra politica applicata secondo programma. Invertirli fa pensare che la piattaforma abbia perso i file.

La scadenza svuota i campi, non elimina i record

La pulizia comprende input, output, URL di callback e contenuti degli eventi e delle callback correlati. Il record dell'attività viene conservato a tempo indeterminato: è l'unica prova su cui si basa una contestazione di fatturazione, e cancellarlo comprometterebbe la contabilità. Dopo la pulizia, ogni riga contiene poche centinaia di byte di metadati: ID dell'attività, modello, stato, importo, date e ore, chiave di origine. La distruzione su richiesta segue esattamente la stessa regola; decidi tu soltanto il momento.

Una volta eliminati i contenuti:

• Puoi ancora rispondere a «quanto mi è stato addebitato questo mese, quali attività sono fallite, quale chiave le ha inviate».
• Non puoi rispondere a «quale prompt ho inviato, quale chiave dell'oggetto identificava il file»: da quel momento recordInfo smette di restituire input e output.

Se vuoi conservare i prompt più a lungo, mantieni una tua copia. Un obbligo di conservazione attivo sospende la cancellazione pertinente e blocca anche la distruzione su richiesta; nessuno dei due meccanismi può ripristinare un output già eliminato fisicamente.

La cronologia del saldo è separata dal contenuto delle attività

Svuotare input e output di un'attività, alla scadenza o perché li hai distrutti, non modifica ricariche, riserve, addebiti finali, riserve restituite o rettifiche manuali. Puoi ancora riconciliare quei movimenti nella pagina di fatturazione della console. I record contabili seguono una politica di conservazione di dieci anni e non vengono rimossi quando il contenuto di un'attività scade o viene distrutto.

Se una richiesta di accesso o cancellazione riguarda dati da conservare per una contestazione, un'indagine di sicurezza o la normativa applicabile, la nostra risposta spiegherà l'ambito e la motivazione.

Due cose che non possiamo fare

L'eccezione: obblighi di conservazione

Le attività coinvolte in una contestazione, una richiesta forense o un obbligo di segnalazione previsto dalla legge vengono sottoposte a un blocco di conservazione e il conteggio verso la scadenza si interrompe fino alla rimozione del blocco. La distruzione su richiesta non viene eseguita mentre il blocco è attivo.

Questo prevale su tutti i valori e tutte le impostazioni descritti sopra. Non è un'eccezione nascosta: senza un meccanismo di blocco, la prima comunicazione legale imporrebbe di violare qualsiasi promessa di conservazione, per poi dover spiegare perché la documentazione dichiarava 14 giorni. Lo dichiariamo qui perché è parte di questa politica.

Le scelte che dipendono da te

• Imposta ogni intervallo alla durata che ti serve davvero. Sono separati: non impostare i caricamenti su «Elimina al termine dell'attività» come effetto collaterale del desiderio di conservare i prompt per meno tempo.
• Scarica prima di abbreviare. Un'impostazione più breve può applicarsi alle attività già eseguite: vedi gli effetti di una modifica.
• Usa X-Spicy-Retention per singole richieste sensibili. Non occorre riconfigurare un intero account per una generazione.
• Non inviare ciò che non serve. Immagini di riferimento e prompt sono i due elementi più sensibili e gli unici due di cui scegli il contenuto.
• Archivia i tuoi file generati. Restano disponibili al massimo per circa 14 giorni, o circa 60 giorni per i contenuti dei cortometraggi, e per meno tempo se riduci l'intervallo.
• Ottieni una copia dei dati dell'account. Scarica i tuoi dati nella pagina Protezione dei dati fornisce un file JSON con profilo, ruoli nei team, dettagli delle chiavi API, mai i segreti, dati delle attività conservati e record di fatturazione. Non include i file multimediali: scarica separatamente i risultati che ti servono.
• Non memorizzare gli URL di download nel database. Scadono dopo 20 minuti e non possono essere revocati dopo l'emissione. Genera un URL firmato quando serve: consulta Contenuti multimediali.
• Usa HTTPS per gli URL di callback. Il payload contiene stato dell'attività e riferimenti ai file; HTTP in chiaro li espone a chiunque si trovi sul percorso.

Non addestriamo modelli sui tuoi contenuti

Prompt, immagini di riferimento e file generati non entrano in alcun set di addestramento.

Il confine di questa frase conta: riguarda noi. Non siamo noi a stabilire le politiche applicate da ciascun modello; vedi il primo punto sopra.