보관과 폐기

보관은 두 계층입니다. 플랫폼 상한은 내부 조정값이 아닌 공개 약속입니다. 그 안에서 더 짧은 자체 기간을 정하거나 원하는 때 작업 하나의 콘텐츠를 폐기할 수 있습니다.

관계는 간단합니다. 단축만 가능하며 어떤 설정도 상한을 늘리지 않습니다.

플랫폼 보관 상한

첫 네 행은 아래 네 보관 기간으로 단축합니다. 생성 결과(미디어·결과 본문), 단편 미디어, 프롬프트 텍스트와 업로드 파일입니다.

단편 영화는 수일·수주에 걸쳐 만들고 첫 주 장면이 전체 내보내기 때도 필요하여 더 오래 보관합니다. Studio 단편 프로젝트 내부 작업만 적용하며 같은 모델의 API·SDK·Playground는 14일입니다. 프롬프트는 어느 경우나 30일입니다. 나머지는 플랫폼 의무·법정 기간으로 설정에 따라 바뀌지 않습니다.

별도로 설정하는 네 기간

한 질문의 네 단계가 아닌 네 가지 별도 목적입니다. 아래는 콘솔의 이름입니다.

콘솔 데이터 보호의 보관에서 설정합니다. 승인 시 설정과 아래 헤더로 작업 자체의 결과·프롬프트 만료를 정하며 recordInfo의 retention으로 읽습니다.

‘작업 종료 시 삭제’는 파일을 사용하는 모든 작업이 종료 상태(succeeded / failed / canceled / expired)에 도달한 뒤 보통 1분 안에 삭제한다는 뜻입니다. 재시도에 필요하므로 생성 시 삭제하지 않습니다. 같은 이미지를 다시 사용하려면 재업로드가 필요하며 retry는 실패한다는 점을 먼저 알아 두세요.

설정 변경이 기존 콘텐츠에 주는 영향

단순히 앞으로만 적용되는 설정이 아닙니다. 일부는 기존 작업에도 적용하며 일부는 아닙니다. 현재 동작은 다음과 같습니다.

소급 이유는 작업 만료를 승인 때 정하는 처리 외에 일 단위 정리가 있기 때문입니다. 프롬프트 설정을 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)입니다. 계정 관리자가 1시간으로 정하면 요청 하나로 14일을 되돌릴 수 없습니다. 그렇지 않으면 설정이 단순 권고가 됩니다.
• 0도 유효하며 종료 상태 즉시 결과 삭제를 뜻합니다.
• 잘못된 값도 요청을 실패시키지 않습니다. 음수는 0, 상한 초과는 상한으로 제한하고 십진 정수가 아니면 무시하여 계정 설정을 적용합니다. 실제 값은 recordInfo의 retention에 나옵니다. 더 보수적인 보관 요청으로 생성이 실패하지 않도록 합니다.
• 적용 엔드포인트. jobs/createTask와 jobs/stream입니다. jobs/retry는 원본 유효값을 상속하고 헤더를 무시합니다. 같은 작업 계열에 만료 두 개를 만들지 않도록 합니다. jobs/quote는 작업을 만들지 않아 읽지 않습니다.

작업별 retention은 recordInfo에 있으며 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

만료를 기다리지 않으려면:

• 콘솔 로그에서 작업을 열고 출력 폐기를 선택하세요. 아래 API와 같습니다.
• 같은 작업의 내역에서 제거도 프롬프트·결과를 지우고 미디어 삭제를 예약하며 추가로 로그에서 숨깁니다. 작업 종료·정산 후 가능합니다.

둘 다 과금 변경·취소가 아닙니다. 코드에서는 다음을 사용합니다.

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지만 객체 정리는 아직 진행 중이며 보통 1분 안에 완료합니다. 동기로 지우면 객체 하나가 전체 요청을 지연할 수 있습니다.
• 여전히 present면 이번 호출이 아무것도 제거하지 않았습니다. 예: 법적 보존. 나중에 재시도 가능하며 이유는 의도적으로 공개하지 않습니다.
• **billingRetained는 항상 true**입니다. 과금 기록 유지가 가장 혼동하기 쉬운 점이라 명시합니다.

contentState: 존재 여부와 제거 주체

상세의 contentState는 세 값입니다.

마지막 두 값에는 purgedAt(제거 시각), contentRemovedBy(정리는 system, 직접은 user)가 있습니다.

purged를 만료로 표시하는 것도 잘못입니다. 직접 누른 동작과 정책에 따른 삭제를 뒤바꾸면 플랫폼이 파일을 분실했다고 생각할 수 있습니다.

만료는 필드를 지우고 기록은 유지

정리는 input, output, 콜백 URL과 관련 이벤트·콜백 콘텐츠를 포함합니다. 작업 기록 자체는 과금 분쟁·회계 증빙으로 무기한 유지합니다. 이후 ID·모델·상태·금액·시각·생성 키의 수백 바이트 메타데이터입니다. 요청 폐기도 같은 규칙이며 시점만 직접 정합니다.

콘텐츠 제거 뒤에도:

• 이번 달 과금, 실패 작업과 생성 키는 확인할 수 있습니다.
• 보낸 프롬프트와 결과 객체 키는 확인할 수 없습니다. recordInfo는 더 이상 input, output을 반환하지 않습니다.

프롬프트가 더 오래 필요하면 자체 사본을 두세요. 활성 보존 조치는 관련 삭제를 중단하고 요청 폐기도 막지만 물리 삭제된 출력은 복구하지 못합니다.

잔액 내역은 작업 콘텐츠와 별개

만료·폐기로 input, output을 지워도 충전·선점·정산·반환·수동 조정은 바뀌지 않습니다. 콘솔 과금에서 대조할 수 있습니다. 원장은 10년 보관하며 작업 콘텐츠 만료·폐기로 제거하지 않습니다.

접근·삭제 요청의 데이터가 분쟁·보안 조사·법률상 보존 대상이면 범위와 이유를 설명합니다.

할 수 없는 두 가지

예외: 법적 보존

분쟁·디지털 증거 조사·법정 신고 의무 관련 작업은 보존 조치 해제까지 보관 시간 계산을 중단합니다. 요청 폐기도 실행되지 않습니다.

위 모든 기간·설정보다 우선합니다. 보존 장치가 없으면 첫 법적 통지부터 보관 약속을 지킬 수 없으므로 숨겨 둔 예외가 아니라 공개해야 하는 규칙입니다.

직접 할 수 있는 조치

• 각 기간을 필요한 길이로 설정하세요. 별개이므로 프롬프트 단축에 따라 업로드까지 작업 종료 삭제로 바꾸지 마세요.
• 단축 전 다운로드. 기존 작업에도 소급될 수 있습니다. 설정 영향 참조.
• 한 번의 민감한 요청에는 X-Spicy-Retention. 계정 전체를 바꿀 필요 없습니다.
• 불필요한 자료는 보내지 마세요. 참조·프롬프트는 가장 민감하며 직접 내용을 고르는 두 항목입니다.
• 자체 결과 보관. 최대 약 14일(단편 약 60일)이며 단축하면 더 짧습니다.
• 계정 데이터 사본. 데이터 보호의 데이터 다운로드는 프로필·팀 역할·API 키 정보(비밀값 제외)·보관 작업·과금 기록의 JSON입니다. 미디어는 없으므로 별도로 받으세요.
• 다운로드 URL을 DB에 저장하지 마세요. 20분에 만료하고 발급 후 취소 불가입니다. 필요 시 서명하세요. 미디어 참조.
• 콜백은 HTTPS. 작업 상태·결과 참조를 담아 일반 HTTP는 경로상의 사람에게 노출합니다.

콘텐츠로 학습하지 않습니다

프롬프트·참조 이미지·결과물은 어떤 학습 데이터에도 넣지 않습니다.

이 약속의 범위는 SpicyAPI입니다. 각 모델의 정책은 저희가 정하지 않습니다. 위 첫 한계를 참고하세요.