Хранение и уничтожение данных

Хранение имеет два уровня. Максимальный срок платформы — публичное обязательство, а не внутренний параметр настройки. В этих пределах вы можете задать собственные, более короткие сроки и в любой момент уничтожить содержимое отдельной задачи.

Соотношение двух уровней простое: срок можно только сократить; никакая ваша настройка не увеличивает максимальный срок.

Как долго мы храним данные: максимальные сроки платформы

Первые четыре строки можно сократить с помощью четырёх отдельных сроков ниже: созданные результаты, включая медиа и данные результата, медиа короткометражных фильмов, текст промптов и загруженные файлы.

У медиа короткометражных фильмов срок больше, потому что фильм в Spicy Studio создаётся днями или неделями: сцена первой недели должна оставаться доступной при экспорте всего фильма. Это относится только к задачам, запущенным в проекте короткометражного фильма Studio. Та же модель через API, SDK или playground сохраняет предел в 14 дней, а текст промпта в любом случае — 30 дней. Остальные сроки являются обязательствами платформы или требованиями закона и не меняются вашими настройками.

Четыре срока, настраиваемые отдельно

Они отвечают на четыре разных вопроса, а не на один вопрос с четырьмя настройками. Ниже приведены названия, показанные в консоли:

Настройте их в разделе Хранение страницы Защита данных консоли. При принятии задачи ей назначаются собственные моменты истечения срока для результатов и промпта на основе этих настроек и заголовка ниже; они доступны в retention ответа recordInfo.

«Удалять после завершения задачи» означает, что загруженный файл удаляется, когда все использующие его задачи достигнут конечного состояния: succeeded / failed / canceled / expired. Обычно это происходит в течение минуты, а не при создании задачи, потому что файл нужен для повторной попытки. Учтите последствия заранее: для повторной генерации с тем же изображением его придётся загрузить заново, а повторная попытка задачи завершится неудачей.

Как изменение настройки влияет на существующие данные

Изменение срока не сводится к переключению «с этого момента». Некоторые изменения затрагивают уже выполненные задачи, другие — нет. Сейчас это работает так:

Почему некоторые изменения затрагивают прошлые задачи: собственные сроки задачи фиксируются при её принятии, но второй проход очистки работает с целыми днями. Он берёт настройку Текст промптов, округляет её вверх до 1, 7 или 30 дней и применяет ко всем завершённым задачам аккаунта. При очистке задачи удаляются вместе и текст промпта, и результаты.

На той же странице есть вторая карточка — Хранение содержимого задач, которая напрямую управляет очисткой по дням:

• Выбор 1 день или 7 дней очищает текст промптов, результаты и созданные файлы каждой задачи, завершившейся более соответствующего срока назад. Очистка продолжается для каждой задачи по достижении этого возраста.
• Включение Удалять вскоре после завершения очищает их для всех завершённых задач, включая задачи, выполненные до включения, примерно через час после завершения каждой.
• Обе карточки используют общие настройки: сохранение одной меняет показания другой.

Переопределение для отдельного запроса: X-Spicy-Retention

Если вы не хотите менять настройку аккаунта, а хотите раньше удалить только одну генерацию, передайте этот заголовок при создании задачи. Значение — целое число секунд; оно относится к файлам и промпту этой задачи:

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"

• Только сокращение. Действующее значение — min(header, account setting, platform cap). Если администратор установил час для аккаунта, отдельный запрос не может вернуть 14 дней: иначе настройка аккаунта была бы лишь рекомендацией.
• 0 допустим и означает удаление файлов сразу после достижения конечного состояния задачи.
• Некорректное значение не вызывает отказ запроса. Отрицательное число ограничивается до 0, значение выше предела — до предела, а значение, не являющееся десятичным целым числом, игнорируется: применяется настройка аккаунта. Фактически применённое значение всегда указывается в retention ответа recordInfo. Заголовок, запрашивающий лишь более осторожное хранение, не должен ломать генерацию.
• Какие эндпоинты учитывают заголовок. Его читают jobs/createTask и jobs/stream. jobs/retry наследует действующее значение исходной задачи и игнорирует заголовок: это вторая попытка того же действия, и возможность выбрать иной срок дала бы одной группе задач два разных срока истечения. jobs/quote не читает его, поскольку не создаёт задачу.

recordInfo возвращает retention для каждой задачи. Сам ответ createTask его не включает, поэтому запросите значение после появления задачи:

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

source показывает определивший срок уровень: header — этот запрос, account — настройка аккаунта, platform — предел платформы. Если вы передали заголовок, но получили account, настройка аккаунта уже была короче запрошенного срока.

До завершения задачи outputsExpireAt отсчитывается от принятия; при достижении конечного состояния отсчёт переносится на момент завершения с тем же интервалом. Поэтому время может сдвигаться только позже, но не раньше. Доверяйте времени в ответе, а не пересчитывайте его самостоятельно: результат трёхуровневого ограничения не всегда совпадает с ожидаемым. Помимо вашего самостоятельного уничтожения, удалить содержимое раньше этих моментов может только настройка аккаунта, затрагивающая прошлые задачи, как описано выше.

Уничтожение содержимого по запросу: POST /jobs/purge

Если вы не хотите ждать истечения срока:

• В консоли откройте задачу в Логи и выберите Уничтожить результаты: это то же действие, что эндпоинт ниже.
• Удалить из истории для той же задачи также очищает её промпт и результат, ставит медиафайлы в очередь на удаление и дополнительно скрывает задачу из вашего журнала. Действие доступно после завершения задачи и окончательного расчёта стоимости.

Ни одно из действий не меняет начисленную сумму и не отменяет задачу. Вызов из кода:

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

Ответ:

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

Несколько правил:

• Только задачи в конечном состоянии: succeeded / failed / canceled / expired. Дождитесь завершения выполняющейся задачи: файлы ещё не получены, а частичное удаление хуже отсутствия удаления. Принятую задачу генерации нельзя отменить, поэтому пути «сначала отменить, затем уничтожить» нет.
• Идемпотентно, без необходимости в Idempotency-Key. Эндпоинт идемпотентен по taskId: повторный вызов для уже уничтоженного содержимого всё равно возвращает 200, а purgedAt содержит время первого уничтожения, а не текущего вызова. Повтор после тайм-аута безопасен.
• Ответ означает «запланировано», а не «уже удалено». Пока mediaDeletionPending равно true, contentState уже имеет значение purged, но фоновая очистка ещё не завершила удаление объектов; обычно она заканчивается в течение минуты. При синхронном удалении один проблемный объект задерживал бы весь запрос именно тогда, когда вам нужен однозначный ответ.
• Ответ со значением present означает, что этот вызов ничего не удалил, например из-за обязательного сохранения данных задачи. Можно повторить позже; конкретная причина намеренно не раскрывается.
• billingRetained всегда равно true. Это кажется избыточным, но поле выделяет главное возможное заблуждение об этом эндпоинте; подробнее ниже.

contentState: осталось ли содержимое и кто его удалил

В подробностях задачи есть contentState с тремя значениями:

Последние два значения сопровождаются purgedAt, временем удаления содержимого, и contentRemovedBy: system для очистки, user для вашего действия.

Отображать purged как «истекло» неверно по той же причине: одно означает нажатие кнопки пользователем, другое — плановое действие политики. Если поменять смыслы, люди решат, что платформа потеряла их файлы.

По истечении срока очищаются поля, а не записи

Очистка охватывает input, output, URL обратного вызова и связанное содержимое событий и обратных вызовов. Сама запись задачи сохраняется бессрочно: это единственное доказательство для спора о начислении, и её удаление нарушило бы учёт. После очистки остаются несколько сотен байт метаданных: ID задачи, модель, состояние, сумма, время и исходный ключ. Уничтожение по запросу следует тому же правилу; вы выбираете только момент.

После удаления содержимого:

• Вы можете узнать, сколько с вас списано за месяц, какие задачи завершились неудачей и какой ключ их отправил.
• Вы не можете узнать отправленный промпт или ключ объекта с файлом результата: с этого момента recordInfo перестаёт возвращать input и output.

Если промпты нужны дольше, сохраняйте собственную копию. Действующее обязательное сохранение приостанавливает соответствующее удаление и блокирует уничтожение по запросу; ни один механизм не может восстановить уже физически удалённый результат.

История баланса отделена от содержимого задач

Очистка input и output задачи по истечении срока или по вашему запросу не меняет пополнения, резервы, окончательные начисления, возвращённые резервы или ручные корректировки. Эти движения баланса по-прежнему можно сверять на странице оплаты в консоли. Финансовые записи хранятся десять лет и не удаляются при истечении срока или уничтожении содержимого задачи.

Если запрос доступа или удаления затрагивает данные, которые нужно сохранить для спора, расследования безопасности или по закону, в ответе мы объясним объём и причину сохранения.

Две вещи, которые мы не можем сделать

Исключение: обязательное сохранение по юридическим основаниям

Задачи, затронутые спором, запросом на экспертизу или законной обязанностью предоставления отчётности, помещаются под обязательное сохранение; отсчёт срока останавливается до снятия этого требования. Пока оно действует, уничтожение по запросу не выполняется.

Это имеет приоритет над всеми цифрами и настройками выше. Это не скрытая лазейка: без такого механизма первое юридическое требование вынудило бы нарушить любое обещание хранения, а затем объяснять, почему документация обещала 14 дней. Это указано здесь, потому что является частью правил хранения.

Что можете сделать вы

• Задайте каждому сроку действительно нужную длительность. Они независимы: не переключайте загрузки на «Удалять после завершения задачи» только из-за желания сократить хранение промптов.
• Скачайте нужное до сокращения срока. Сокращение может затронуть уже выполненные задачи; см. последствия изменения настроек.
• Используйте X-Spicy-Retention для отдельных чувствительных запросов. Для одной генерации не нужно перенастраивать весь аккаунт.
• Не отправляйте лишнее. Референсные изображения и промпты — два самых чувствительных вида данных и единственные два, содержимое которых вы выбираете сами.
• Архивируйте свои результаты самостоятельно. Они хранятся не дольше примерно 14 дней, около 60 дней для медиа короткометражных фильмов, и меньше при сокращении срока.
• Скопируйте данные своего аккаунта. Кнопка Скачать ваши данные на странице Защита данных выдаёт JSON-файл с профилем, ролями в команде, сведениями об API-ключах без секретов, сохранёнными данными задач и финансовыми записями. Медиафайлы в него не входят: скачивайте нужные результаты отдельно.
• Не храните URL скачивания в базе данных. Они истекают через 20 минут, и их нельзя отозвать после выдачи. Создавайте подписанную ссылку, когда она нужна; см. Медиафайлы.
• Используйте HTTPS для URL обратного вызова. Тело содержит состояние задачи и ссылки на файлы результата; обычный HTTP открывает их любому участнику передачи.

Мы не обучаем модели на вашем содержимом

Ваши промпты, референсные изображения и результаты не попадают ни в один наш обучающий набор.

Граница этой фразы важна: она относится к нам. Мы не устанавливаем политики отдельных моделей; см. первый пункт выше.