Aufbewahrung und Löschung

Die Aufbewahrung hat zwei Ebenen. Die Obergrenze der Plattform ist eine öffentliche Zusage und kein interner Einstellungsregler. Innerhalb dieser Grenze können Sie eigene kürzere Fristen festlegen. Außerdem können Sie den Inhalt eines einzelnen Tasks jederzeit zur Löschung freigeben.

Das Verhältnis der Ebenen lässt sich einfach ausdrücken: Sie können Fristen nur verkürzen; keine Ihrer Einstellungen verlängert die Obergrenze.

Wie lange wir Daten aufbewahren

Die ersten vier Zeilen können Sie mit den folgenden vier getrennten Fristen verkürzen: generierte Ergebnisse, also Medien und Ergebnisdaten, Kurzfilmmedien, Prompttexte und hochgeladene Dateien.

Kurzfilmmedien erhalten die längere Frist, weil ein Film in Spicy Studio über Tage oder Wochen entsteht. Eine Szene aus der ersten Woche muss beim Export des gesamten Films noch vorhanden sein. Dies gilt nur für Tasks, die innerhalb eines Studio-Kurzfilmprojekts gestartet wurden. Dasselbe Modell über API, SDK oder Playground behält die 14-Tage-Grenze; Prompttexte behalten in beiden Fällen die 30-Tage-Grenze. Die übrigen Fristen sind Verpflichtungen der Plattform oder gesetzliche Fristen und ändern sich nicht mit Ihren Einstellungen.

Vier getrennt einstellbare Fristen

Sie beantworten vier unterschiedliche Fragen und sind nicht vier Varianten derselben Einstellung. Die folgenden Namen entsprechen den Bezeichnungen in der Konsole:

Legen Sie diese unter Aufbewahrung auf der Seite Datenschutz fest. Bei Annahme erhält jeder Task eigene Ablaufzeitpunkte für Ergebnis und Prompt aus diesen Einstellungen und dem unten beschriebenen Header. Sie können sie unter retention in recordInfo lesen.

„Nach Auftragsende löschen“ bedeutet, dass eine hochgeladene Datei gelöscht wird, sobald jeder sie verwendende Task einen Endzustand erreicht hat, also succeeded / failed / canceled / expired, normalerweise innerhalb einer Minute. Sie wird nicht bei Erstellung des Tasks gelöscht, weil ein erneuter Versuch sie benötigt. Beachten Sie die Folge: Für eine weitere Generierung mit demselben Bild müssen Sie es erneut hochladen; ein Retry wird scheitern.

Wirkung geänderter Einstellungen auf vorhandene Inhalte

Eine Friständerung gilt nicht einfach nur „ab jetzt“. Manche Änderungen wirken auf bereits ausgeführte Tasks zurück, andere nicht. Derzeit gilt:

Der Grund für Rückwirkungen: Die eigenen Ablaufzeitpunkte jedes Tasks werden bei Annahme festgelegt. Ein zweiter Bereinigungslauf arbeitet jedoch in ganzen Tagen. Er übernimmt Ihre Prompttext-Einstellung, rundet sie auf 1, 7 oder 30 Tage und wendet sie auf alle abgeschlossenen Tasks des Kontos an. Bei der Bereinigung leert er Prompttext und Ergebnisse gemeinsam.

Dieselbe Seite enthält eine zweite Karte, Aufbewahrung von Auftragsinhalten, die diesen tageweisen Lauf direkt steuert:

• 1 Tag oder 7 Tage löscht Prompttext, Ergebnisse und generierte Dateien jedes Tasks, der seit mehr als dieser Zeit abgeschlossen ist. Für weitere Tasks geschieht es jeweils beim Erreichen dieses Alters.
• Inhalte kurz nach Abschluss löschen entfernt sie bei jedem abgeschlossenen Task, auch bei bereits vor Aktivierung ausgeführten Tasks, etwa eine Stunde nach dessen Abschluss.
• Die beiden Karten teilen ihre Einstellungen. Speichern einer Karte ändert die Anzeige der anderen.

Überschreibung je Anfrage: X-Spicy-Retention

Soll nur diese Generierung früher verschwinden, ohne die Kontoeinstellung zu ändern, senden Sie den Header bei Taskerstellung. Der Wert ist eine ganze Zahl in Sekunden und gilt für Dateien und Prompt dieses Tasks:

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"

• Nur verkürzen. Der effektive Wert lautet min(header, account setting, platform cap). Hat ein Administrator das Konto auf eine Stunde gesetzt, kann eine einzelne Anfrage keine 14 Tage zurückholen. Sonst wäre die Kontoeinstellung nur eine Empfehlung.
• 0 ist gültig und bedeutet „Dateien löschen, sobald der Task einen Endzustand erreicht“.
• Ein ungültiger Wert lässt die Anfrage nicht scheitern. Negative Zahlen werden auf 0 begrenzt; Werte über der Obergrenze auf diese Grenze. Ein Wert, der keine dezimale Ganzzahl ist, wird ignoriert, sodass die Kontoeinstellung gilt. Der tatsächlich wirksame Wert steht immer als retention in recordInfo. Ein Header, der lediglich vorsichtigere Aufbewahrung verlangt, soll keine Generierung verhindern.
• Welche Endpunkte ihn lesen: jobs/createTask und jobs/stream tun dies. jobs/retry übernimmt den effektiven Wert des ursprünglichen Tasks und ignoriert den Header. Ein Retry ist ein zweiter Versuch derselben Aufgabe; unterschiedliche Fristen würden einer Taskfamilie zwei Ablaufzeiten geben. jobs/quote liest ihn nicht, weil es keinen Task erstellt.

recordInfo liefert retention je Task; die Antwort von createTask enthält es nicht. Lesen Sie es, sobald der Task existiert:

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

source nennt die bestimmende Ebene: header für diese Anfrage, account für die Kontoeinstellung oder platform für die Obergrenze. Wenn Sie den Header senden und dennoch account erhalten, war die Kontoeinstellung bereits kürzer als Ihr angefragter Wert.

Vor Taskabschluss wird outputsExpireAt ab der Annahme berechnet. Beim Erreichen eines Endzustands wird derselbe Zeitraum auf die Abschlusszeit bezogen. Der Zeitpunkt wandert daher nur nach hinten, nie nach vorne. Vertrauen Sie den Zeitstempeln der Antwort, statt sie selbst neu zu berechnen. Die Begrenzung durch drei Ebenen führt nicht immer zum erwarteten Ergebnis. Außer Ihrer eigenen Löschanforderung kann nur eine rückwirkende Kontoeinstellung Inhalte früher entfernen, wie oben beschrieben.

Inhalte auf Anforderung löschen: POST /jobs/purge

Wenn Sie nicht auf den Ablauf warten möchten:

• Öffnen Sie in der Konsole den Task unter Logs und wählen Sie Ausgaben löschen. Dies entspricht dem folgenden Endpunkt.
• Aus Verlauf entfernen beim selben Task leert ebenfalls Prompt und Ergebnis und stellt die Medien zur Löschung ein. Zusätzlich wird der Task aus Ihrem Log ausgeblendet. Dies ist möglich, sobald der Task beendet und die Abrechnung abgeschlossen ist.

Keine der Aktionen ändert Ihre Kosten oder bricht einen Task ab. Aus Ihrem Code:

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..."}'

Die Antwort:

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

Es gelten einige Regeln:

• Nur abgeschlossene Tasks, also succeeded / failed / canceled / expired. Warten Sie auf den Abschluss laufender Tasks. Die Dateien liegen noch nicht vor; eine halbe Löschung wäre schlechter als keine. Ein angenommener Generierungstask kann nicht abgebrochen werden. Es gibt daher keinen Ablauf „erst abbrechen, dann löschen“.
• Idempotent; kein Idempotency-Key erforderlich. Der Endpunkt ist anhand der taskId idempotent. Ein erneuter Aufruf für einen bereits gelöschten Task liefert weiterhin 200. purgedAt bezeichnet die erste Löschanforderung, nicht diesen Aufruf. Wiederholung nach einem Timeout ist sicher.
• Die Antwort bedeutet „eingeplant“, nicht „bereits gelöscht“. Solange mediaDeletionPending wahr ist, steht contentState bereits auf purged, während der Hintergrundlauf die Objekte noch entfernt. Er endet normalerweise innerhalb einer Minute. Eine synchrone Löschung würde erlauben, dass ein hartnäckiges Objekt die gesamte Anfrage blockiert, gerade wenn Sie eine klare Antwort brauchen.
• Eine Antwort mit weiterhin present bedeutet, dass der Aufruf nichts entfernt hat, etwa wegen einer Aufbewahrungssperre. Sie können es später erneut versuchen; der konkrete Grund wird bewusst nicht offengelegt.
• billingRetained ist immer true. Es wirkt überflüssig, erinnert aber an den bei diesem Endpunkt am ehesten missverstandenen Punkt; siehe unten.

contentState: Vorhandensein und Urheber der Löschung

Taskdetails enthalten contentState mit drei Werten:

Die letzten beiden enthalten purgedAt für den Zeitpunkt der Entfernung und contentRemovedBy, mit system für den Bereinigungslauf oder user für Sie.

purged als „abgelaufen“ anzuzeigen wäre aus umgekehrtem Grund falsch: Das eine ist eine vom Nutzer ausgelöste Aktion, das andere eine planmäßig ausgeführte Richtlinie. Vertauschte Bezeichnungen lassen Menschen glauben, die Plattform habe ihre Dateien verloren.

Ablauf leert Felder, nicht Datensätze

Die Bereinigung umfasst input, output, Callback-URLs sowie zugehörige Ereignis- und Callback-Inhalte. Der Taskdatensatz selbst bleibt unbefristet erhalten. Er ist die einzige Beleggrundlage eines Abrechnungsstreitfalls; seine Löschung würde die Buchführung beschädigen. Danach enthält jede Zeile wenige hundert Bytes Metadaten: Task-ID, Modell, Zustand, Betrag, Zeitstempel und ursprünglicher Key. Die Löschung auf Wunsch folgt derselben Regel; nur den Zeitpunkt bestimmen Sie.

Nach Entfernung des Inhalts gilt:

• Sie können weiterhin beantworten: „Was wurde mir diesen Monat berechnet, welche Tasks schlugen fehl und welcher Key reichte sie ein?“
• Sie können nicht beantworten: „Welchen Prompt habe ich gesendet und unter welchem Objektschlüssel lag die Datei?“ Ab dann liefert recordInfo weder input noch output.

Benötigen Sie Prompts länger, behalten Sie eine eigene Kopie. Eine aktive Aufbewahrungssperre setzt die betreffende Löschung aus und blockiert auch gezielte Löschanforderungen. Keine der beiden Funktionen kann eine bereits physisch gelöschte Ausgabe wiederherstellen.

Guthabenverlauf und Taskinhalte sind getrennt

Das Leeren von input und output nach Ablauf oder auf Ihre Anforderung ändert keine Aufladungen, Reservierungen, Abrechnungen, freigegebenen Reservierungen oder manuellen Korrekturen. Diese Guthabenbewegungen können Sie weiter auf der Abrechnungsseite abgleichen. Buchungsdatensätze unterliegen einer zehnjährigen Aufbewahrung und werden bei Ablauf oder Löschung von Taskinhalten nicht entfernt.

Betrifft eine Auskunfts- oder Löschanfrage Daten, die für einen Streitfall, eine Sicherheitsuntersuchung oder nach geltendem Recht behalten werden müssen, erläutert unsere Antwort Umfang und Grund.

Zwei Dinge, die wir nicht leisten können

Ausnahme: Rechtliche Aufbewahrungssperren

Tasks, die von einem Streitfall, einer forensischen Anfrage oder einer gesetzlichen Meldepflicht betroffen sind, erhalten eine Aufbewahrungssperre. Ihr Ablauf wird angehalten, bis die Sperre aufgehoben wird. Währenddessen werden Löschanforderungen nicht ausgeführt.

Dies hat Vorrang vor allen genannten Werten und Einstellungen. Es ist kein stillschweigend vorbehaltener Hintereingang: Ohne Sperrmechanismus würde schon das erste rechtliche Schreiben eine Aufbewahrungszusage durchbrechen. Dann müssten wir erklären, warum die Dokumentation 14 Tage nannte. Diese Ausnahme steht hier, weil sie hier hingehört.

Was Sie selbst steuern

• Wählen Sie jede Frist nach Ihrem tatsächlichen Bedarf. Sie sind getrennt. Stellen Sie Uploads nicht beiläufig auf „Nach Auftragsende löschen“, nur weil Sie Prompts kürzer aufbewahren möchten.
• Laden Sie vor dem Verkürzen herunter. Kürzere Einstellungen können auf bereits ausgeführte Tasks zurückwirken; siehe Wirkung einer geänderten Einstellung.
• Verwenden Sie X-Spicy-Retention für einzelne sensible Anfragen. Für eine Generierung müssen Sie nicht das ganze Konto umstellen.
• Senden Sie nur erforderliche Daten. Referenzbilder und Prompts sind die beiden sensibelsten Elemente und die beiden, deren Inhalt Sie selbst wählen.
• Archivieren Sie Ihre Dateien selbst. Sie bleiben höchstens etwa 14 Tage, Kurzfilmmedien etwa 60 Tage, und bei kürzerer Einstellung entsprechend weniger.
• Kopieren Sie Ihre Kontodaten. Ihre Daten herunterladen auf der Datenschutzseite liefert JSON mit Profil, Teamrollen, API-Key-Details ohne Geheimnisse, aufbewahrten Taskdaten und Buchungsdatensätzen. Mediendateien fehlen darin; laden Sie gewünschte Ergebnisse getrennt herunter.
• Speichern Sie keine Download-URLs in Ihrer Datenbank. Sie laufen nach 20 Minuten ab und können nach Ausstellung nicht widerrufen werden. Lassen Sie eine URL erst bei Bedarf signieren; siehe Medien.
• Verwenden Sie HTTPS für Callback-URLs. Die Nutzdaten enthalten Taskzustand und Dateiverweise. Unverschlüsseltes HTTP legt sie allen auf dem Übertragungsweg offen.

Wir trainieren nicht mit Ihren Inhalten

Ihre Prompts, Referenzbilder und erzeugten Dateien fließen in keinen Trainingsdatensatz ein.

Die Grenze dieser Aussage ist entscheidend: Sie betrifft uns. Die Richtlinien des jeweiligen Modells bestimmen nicht wir; siehe den ersten Punkt oben.