Przechowywanie i usuwanie danych

Przechowywanie danych ma dwie warstwy. Limit platformy jest publicznym zobowiązaniem, a nie wewnętrznym ustawieniem technicznym. W jego granicach możesz ustawić własne, krótsze okresy — oraz usunąć treść pojedynczego zadania w dowolnym momencie.

Zależność między tymi warstwami jest prosta: możesz tylko skracać okres; żadne Twoje ustawienie nie wydłuża limitu platformy.

Jak długo przechowujemy dane — limity platformy

Pierwsze cztery wiersze można skrócić przy użyciu opisanych niżej czterech okresów: wygenerowanych wyników (plików i danych wyniku), materiałów krótkich filmów, tekstu promptów i przesłanych plików.

Materiały krótkiego filmu mają dłuższy okres, ponieważ film w Spicy Studio powstaje przez dni lub tygodnie, a scena utworzona w pierwszym tygodniu musi nadal istnieć przy eksporcie całego filmu. Dotyczy to wyłącznie zadań uruchomionych wewnątrz projektu krótkiego filmu w Studio; ten sam model wywołany przez API, SDK lub playground zachowuje limit 14 dni, a tekst promptu w obu przypadkach — 30 dni. Pozostałe okresy wynikają z obowiązków platformy lub prawa i nie zmieniają się wraz z Twoimi ustawieniami.

Cztery okresy ustawiane oddzielnie

Odpowiadają na cztery różne pytania, a nie na jedno pytanie w czterech wariantach. Poniższe nazwy odpowiadają ustawieniom widocznym w konsoli:

Ustawisz je w sekcji Przechowywanie danych na stronie Ochrona danych w konsoli. Przyjęte zadanie otrzymuje własne terminy wygaśnięcia wyników i promptów na podstawie tych ustawień oraz opisanego niżej nagłówka; odczytasz je jako retention w recordInfo.

„Usuń po zakończeniu zadania” oznacza, że przesłany plik jest usuwany, gdy każde korzystające z niego zadanie osiągnie stan końcowy (succeeded / failed / canceled / expired), zwykle w ciągu minuty — nie przy utworzeniu zadania, ponieważ plik jest potrzebny do ponowienia. Uwzględnij konsekwencję: ponowne użycie tego samego obrazu wymaga ponownego przesłania, a ponowienie zadania zakończy się niepowodzeniem.

Jak zmiana ustawienia wpływa na istniejące dane

Zmiana okresu nie jest prostym przełącznikiem „od teraz”. Niektóre zmiany obejmują zadania wykonane wcześniej, inne nie. Obecnie działa to tak:

Dlaczego niektóre zmiany obejmują wcześniejsze dane: własne terminy zadania są ustalane przy jego przyjęciu, lecz drugi proces czyszczenia działa w pełnych dniach. Pobiera ustawienie Tekstu promptów, zaokrągla je w górę do 1, 7 lub 30 dni i stosuje do wszystkich zakończonych zadań na koncie — a przy czyszczeniu zadania usuwa jednocześnie tekst promptu i wyniki.

Ta sama strona zawiera drugą kartę, Przechowywanie treści zadań, która bezpośrednio steruje czyszczeniem według dni:

• Wybór 1 dnia lub 7 dni usuwa tekst promptu, wyniki i wygenerowane pliki każdego zadania zakończonego wcześniej niż wskazany okres oraz dalej usuwa je, gdy kolejne zadania osiągają ten wiek.
• Włączenie Usuń treść wkrótce po zakończeniu usuwa je dla wszystkich zakończonych zadań — również uruchomionych przed włączeniem opcji — około godziny po zakończeniu każdego z nich.
• Obie karty korzystają ze wspólnych ustawień: zapis jednej zmienia wartości wyświetlane w drugiej.

Ustawienie dla jednego żądania: X-Spicy-Retention

Jeżeli nie chcesz zmieniać ustawienia konta, ale chcesz wcześniej usunąć to jedno generowanie, wyślij nagłówek podczas tworzenia zadania. Wartość to całkowita liczba sekund, odnosząca się do plików i promptu tego zadania:

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"

• Tylko krótszy okres. Wartość efektywna wynosi min(header, account setting, platform cap). Gdy administrator ustawi na koncie jedną godzinę, pojedyncze żądanie nie może przywrócić 14 dni — inaczej ustawienie konta byłoby tylko sugestią.
• 0 jest prawidłową wartością i oznacza „usuń pliki, gdy tylko zadanie osiągnie stan końcowy”.
• Nieprawidłowa wartość nie powoduje niepowodzenia żądania. Liczba ujemna jest ograniczana do 0; wartość ponad limit — do limitu; wartość niebędąca dziesiętną liczbą całkowitą jest ignorowana, więc obowiązuje ustawienie konta. Rzeczywiście zastosowaną wartość zawsze raportuje retention w recordInfo. Nagłówek, który ma tylko skrócić przechowywanie, nie powinien przerywać generowania.
• Endpointy, które go odczytują. Odczytują go jobs/createTask i jobs/stream. jobs/retry dziedziczy efektywną wartość zadania źródłowego i ignoruje nagłówek — ponowienie jest drugą próbą tego samego zadania, a wybór innego okresu tworzyłby dwa terminy wygaśnięcia w jednej rodzinie zadań. jobs/quote go nie odczytuje, ponieważ nie tworzy zadania.

recordInfo zwraca retention dla każdego zadania; sama odpowiedź createTask go nie zawiera, więc odczytaj go po utworzeniu zadania:

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

source wskazuje warstwę, która rozstrzygnęła: header (to żądanie), account (ustawienie konta) lub platform (limit). Jeżeli wyślesz nagłówek, a nadal otrzymasz account, ustawienie konta było już krótsze niż żądany okres.

Przed zakończeniem zadania outputsExpireAt jest liczony od przyjęcia; po osiągnięciu stanu końcowego jest przeliczany od zakończenia, z zachowaniem tego samego okresu. Może więc przesunąć się tylko na później, nigdy na wcześniej. Korzystaj ze znaczników czasu w odpowiedzi, zamiast przeliczać je samodzielnie — wynik ograniczenia przez trzy warstwy nie zawsze jest taki, jak oczekujesz. Oprócz samodzielnego usunięcia jedyną przyczyną wcześniejszego usunięcia treści jest ustawienie konta obejmujące wcześniejsze dane, opisane wyżej.

Usuwanie treści na żądanie: POST /jobs/purge

Jeżeli nie chcesz czekać na wygaśnięcie:

• W konsoli otwórz zadanie w Logach i wybierz Usuń wyniki — to ta sama operacja co poniższy endpoint.
• Usuń z historii w tym samym zadaniu również czyści prompt i wynik oraz kolejkuje usunięcie plików, a dodatkowo ukrywa zadanie w Twoich logach. Opcja jest dostępna po zakończeniu zadania i rozliczeniu opłaty.

Żadna z tych operacji nie zmienia naliczonej opłaty ani nie anuluje zadania. W kodzie:

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

Odpowiedź:

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

Kilka zasad:

• Tylko zadania w stanie końcowym (succeeded / failed / canceled / expired). Poczekaj na zakończenie działającego zadania: pliki jeszcze nie zostały zapisane, a częściowe usunięcie byłoby gorsze od jego braku. Przyjętego zadania generowania nie można anulować, więc nie ma ścieżki „najpierw anuluj, potem usuń”.
• Operacja jest idempotentna i nie wymaga Idempotency-Key. Idempotencja opiera się na taskId: kolejne wywołanie dla zadania, którego treść już usunięto, nadal zwraca 200, a purgedAt oznacza moment pierwszego usunięcia, nie bieżącego wywołania. Ponowienie po przekroczeniu czasu jest bezpieczne.
• Odpowiedź oznacza „zaplanowano”, nie „już usunięto”. Gdy mediaDeletionPending jest prawdziwe, contentState ma już wartość purged, lecz proces w tle nie zakończył usuwania obiektów; zwykle kończy je w ciągu minuty. Usuwanie synchroniczne pozwalałoby jednemu problematycznemu obiektowi zablokować całe żądanie właśnie wtedy, gdy potrzebujesz jednoznacznej odpowiedzi.
• Odpowiedź nadal zawierająca present oznacza, że wywołanie niczego nie usunęło — na przykład z powodu obowiązku zachowania danych zadania. Możesz spróbować później; konkretny powód celowo nie jest ujawniany.
• billingRetained zawsze ma wartość true. Może wyglądać na zbędne, ale zapobiega najbardziej prawdopodobnemu błędnemu założeniu dotyczącemu tego endpointu — wyjaśniamy je niżej.

contentState: czy treść istnieje i kto ją usunął

Szczegóły zadania zawierają contentState z trzema wartościami:

Dwie ostatnie wartości występują wraz z purgedAt (momentem usunięcia treści) i contentRemovedBy (system dla procesu czyszczenia, user dla Ciebie).

Pokazywanie purged jako „wygasło” jest błędne z tego samego powodu, tylko w przeciwną stronę: jedno wynika z naciśnięcia przycisku przez użytkownika, drugie z naszych zasad wykonywanych zgodnie z harmonogramem. Pomylenie tych znaczeń sprawia, że użytkownik może uznać, iż platforma zgubiła jego pliki.

Wygaśnięcie czyści pola, nie rekordy

Czyszczenie obejmuje input, output, adresy callbacków oraz powiązaną treść zdarzeń i callbacków. Sam rekord zadania pozostaje bezterminowo — jest jedynym dowodem w sporze dotyczącym rozliczenia, a jego usunięcie zaburzyłoby księgi. Po czyszczeniu rekord zawiera kilkaset bajtów metadanych: ID zadania, model, stan, kwotę, znaczniki czasu i klucz, który je wysłał. Usuwanie na żądanie stosuje dokładnie tę samą zasadę; wybierasz jedynie moment.

Gdy treść zniknie:

• Nadal możesz odpowiedzieć na pytania: „ile naliczono mi w tym miesiącu, które zadania się nie powiodły, który klucz je wysłał”.
• Nie możesz odpowiedzieć: „jaki prompt wysłano, pod jakim kluczem obiektu zapisano plik” — od tej chwili recordInfo nie zwraca input i output.

Jeżeli potrzebujesz promptów dłużej, zachowaj własną kopię. Aktywny obowiązek zachowania danych wstrzymuje ich usuwanie i blokuje usuwanie na żądanie; żaden z tych mechanizmów nie przywraca wyniku, który już fizycznie usunięto.

Historia salda jest oddzielona od treści zadania

Wyczyszczenie input i output zadania — po wygaśnięciu albo na Twoje żądanie — nie zmienia wpłat, rezerwacji, rozliczeń, zwolnionych rezerwacji ani ręcznych korekt. Nadal możesz uzgodnić te zmiany salda na stronie rozliczeń w konsoli. Rekordy operacji rozliczeniowych są przechowywane przez dziesięć lat i nie są usuwane wraz z wygaśnięciem lub usunięciem treści zadania.

Jeżeli żądanie dostępu lub usunięcia obejmuje dane, które musimy zachować ze względu na spór, dochodzenie dotyczące bezpieczeństwa lub obowiązujące prawo, wyjaśnimy zakres i powód w odpowiedzi.

Dwie rzeczy, których nie możemy zapewnić

Wyjątek: obowiązek zachowania danych

Zadania objęte sporem, wnioskiem związanym z analizą dowodów lub ustawowym obowiązkiem zgłoszenia są obejmowane obowiązkiem zachowania danych i ich okres przestaje upływać do czasu zwolnienia tego obowiązku. W tym czasie usuwanie na żądanie nie jest wykonywane.

Ma to pierwszeństwo przed każdym okresem i ustawieniem opisanym wyżej. Nie jest to ukryty wyjątek: bez takiego mechanizmu pierwsze pismo prawne wymuszałoby złamanie obietnicy przechowywania, a potem należałoby wyjaśnić, dlaczego dokumentacja podawała 14 dni. Opisujemy go tutaj, ponieważ należy do tych zasad.

Co możesz kontrolować

• Ustaw każdy okres zgodnie z rzeczywistą potrzebą. Są niezależne: nie wybieraj dla przesłanych plików „Usuń po zakończeniu zadania” tylko dlatego, że chcesz krócej przechowywać prompty.
• Pobierz dane przed skróceniem okresu. Krótsze ustawienie może objąć zadania wykonane wcześniej — zobacz skutki zmiany ustawienia.
• Używaj X-Spicy-Retention dla pojedynczych wrażliwych żądań. Nie musisz zmieniać konfiguracji całego konta dla jednego generowania.
• Nie wysyłaj zbędnych danych. Obrazy referencyjne i prompty są dwoma najbardziej wrażliwymi rodzajami danych oraz jedynymi dwoma, których treść wybierasz.
• Archiwizuj własne pliki. Pozostają dostępne maksymalnie około 14 dni (około 60 dni dla materiałów krótkich filmów), a krócej, jeżeli skrócisz okres.
• Pobierz kopię danych konta. Opcja Pobierz swoje dane na stronie Ochrona danych daje plik JSON z profilem, rolami zespołowymi, szczegółami kluczy API (nigdy ich sekretami), zachowanymi danymi zadań i rekordami rozliczeń. Nie zawiera plików multimedialnych — potrzebne wyniki pobierz osobno.
• Nie zapisuj adresów pobierania w bazie danych. Wygasają po 20 minutach i nie można ich unieważnić po wystawieniu. Generuj podpisany adres wtedy, gdy go potrzebujesz — zobacz Pliki multimedialne.
• Używaj HTTPS dla adresów callbacków. Treść zawiera stan zadania i odwołania do plików; zwykły HTTP ujawnia je każdemu, kto ma dostęp do transmisji.

Nie trenujemy na Twoich treściach

Twoje prompty, obrazy referencyjne i wygenerowane pliki nie trafiają do żadnego zbioru treningowego.

Granica tego stwierdzenia ma znaczenie: dotyczy nas. Nie ustalamy zasad obowiązujących dla poszczególnych modeli — zobacz pierwszy punkt wyżej.