Conservation et suppression

La conservation comporte deux niveaux. Le plafond de la plateforme est un engagement public, pas un réglage interne. Dans cette limite, vous pouvez définir vos propres délais, plus courts, et supprimer le contenu d’une tâche quand vous le souhaitez.

La relation entre ces deux niveaux tient en une phrase : vous pouvez uniquement raccourcir les délais ; aucun réglage ne prolonge le plafond.

Durées de conservation : plafonds de la plateforme

Les quatre délais ci-dessous permettent de raccourcir les quatre premières lignes : résultats générés, comprenant les médias et les données du résultat, médias de courts-métrages, texte des prompts et fichiers téléversés.

Les médias de courts-métrages bénéficient d’un délai plus long, car un film Spicy Studio se construit sur plusieurs jours ou semaines : une scène créée la première semaine doit encore être disponible lors de l’export du film complet. Cela concerne uniquement les tâches lancées dans un projet de court-métrage du Studio. Un appel au même modèle via l’API, un SDK ou le playground conserve le plafond de 14 jours ; le texte des prompts conserve celui de 30 jours dans tous les cas. Les autres délais relèvent des obligations de la plateforme ou de durées légales et ne changent pas avec vos réglages.

Quatre délais indépendants

Ils répondent à quatre questions différentes, et non à une seule question avec quatre valeurs. Les noms ci-dessous sont ceux affichés dans la console :

Configurez-les dans Conservation, sur la page Protection des données de la console. À l’acceptation d’une tâche, ses propres dates d’expiration des résultats et des prompts sont calculées selon ces réglages et l’en-tête décrit plus bas ; vous pouvez les lire dans retention, au sein de recordInfo.

« Supprimer à la fin du traitement » signifie qu’un fichier téléversé est supprimé lorsque toutes les tâches qui l’utilisent ont atteint un état final : succeeded / failed / canceled / expired, normalement dans la minute qui suit. Il n’est pas supprimé à la création de la tâche, car une nouvelle tentative peut en avoir besoin. Tenez compte de la conséquence avant de choisir ce réglage : réutiliser la même image impose de la téléverser à nouveau, et une relance échouera.

Effet d’un changement de réglage sur les contenus existants

Modifier un délai ne revient pas simplement à changer les règles « à partir de maintenant ». Certains changements s’appliquent aux tâches déjà exécutées, d’autres non. Voici le fonctionnement actuel :

Certains changements touchent l’historique parce que, même si chaque tâche reçoit des dates d’expiration fixes à l’acceptation, un second nettoyage fonctionne en jours entiers. Il prend le réglage Texte des prompts, l’arrondit au supérieur à 1, 7 ou 30 jours, puis l’applique à toutes les tâches terminées du compte. Lorsqu’il efface une tâche, il efface ensemble le texte du prompt et les résultats.

La même page comporte une deuxième carte, Conservation du contenu des tâches, qui pilote directement ce nettoyage par jours :

• Choisir 1 jour ou 7 jours efface le texte du prompt, les résultats et les fichiers générés de toutes les tâches terminées depuis plus longtemps, puis continue à le faire lorsque chaque tâche atteint cet âge.
• Activer Effacer le contenu peu après la fin les efface pour toutes les tâches terminées, y compris celles exécutées avant l’activation, environ une heure après la fin de chaque tâche.
• Les deux cartes partagent les réglages : enregistrer l’une modifie ce qu’affiche l’autre.

Réglage par requête : X-Spicy-Retention

Pour faire disparaître plus tôt une seule génération sans modifier le réglage du compte, envoyez cet en-tête lors de la création de la tâche. Sa valeur est un entier en secondes, applicable aux fichiers et au prompt de cette tâche :

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"

• Uniquement pour raccourcir. La valeur effective est min(header, account setting, platform cap). Si un administrateur règle le compte sur une heure, une requête individuelle ne peut pas revenir à 14 jours ; autrement, le réglage du compte ne serait qu’une suggestion.
• 0 est valide et signifie « supprimer les fichiers dès que la tâche atteint un état final ».
• Une valeur invalide ne fait pas échouer la requête. Un nombre négatif est ramené à 0, une valeur dépassant le plafond est ramenée au plafond et toute valeur qui n’est pas un entier décimal est ignorée : le réglage du compte s’applique alors. La valeur effectivement utilisée est toujours indiquée dans retention, au sein de recordInfo. Un en-tête demandant uniquement une conservation plus courte ne doit jamais casser une génération.
• Points de terminaison concernés. jobs/createTask et jobs/stream le lisent tous les deux. jobs/retry hérite de la valeur effective de la tâche d’origine et ignore l’en-tête : une relance est une deuxième tentative de la même opération ; autoriser une durée différente donnerait deux expirations à une même famille de tâches. jobs/quote ne le lit pas, car il ne crée aucune tâche.

recordInfo renvoie retention pour chaque tâche ; la réponse de createTask ne l’inclut pas. Consultez-le une fois la tâche créée :

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

source indique le niveau qui a déterminé le délai : header pour cette requête, account pour le réglage du compte ou platform pour le plafond. Si vous envoyez l’en-tête et obtenez tout de même account, le réglage du compte était déjà plus court que votre demande.

Avant la fin de la tâche, outputsExpireAt est calculé depuis l’acceptation ; lorsque la tâche atteint un état final, il est recalculé depuis la fin du traitement, avec la même fenêtre. Il peut donc seulement être repoussé, jamais avancé. Fiez-vous aux horodatages de la réponse plutôt que de les recalculer : le résultat des trois limites n’est pas toujours celui attendu. Hormis une suppression demandée par vous, seul un réglage de compte rétroactif peut supprimer le contenu avant ces dates, comme expliqué plus haut.

Supprimer le contenu à la demande : POST /jobs/purge

Si vous ne souhaitez pas attendre l’expiration :

• Dans la console, ouvrez la tâche dans Journaux et choisissez Supprimer les résultats : c’est la même action que le point de terminaison ci-dessous.
• Retirer de l’historique, sur cette même tâche, efface aussi le prompt et le résultat, met les médias en file de suppression et masque en plus la tâche dans votre journal. Cette action est disponible lorsque la tâche est terminée et la facturation réglée.

Aucune de ces actions ne modifie les frais ni n’annule une tâche. Depuis votre 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..."}'

La réponse :

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

Quelques règles :

• Uniquement les tâches terminées : succeeded / failed / canceled / expired. Attendez la fin d’une tâche en cours : les fichiers ne sont pas encore disponibles et une suppression partielle serait plus problématique qu’aucune suppression. Une tâche de génération ne peut pas être annulée après acceptation ; il n’existe donc aucun parcours « annuler, puis supprimer ».
• L’action est idempotente et ne nécessite pas de Idempotency-Key. Le point de terminaison est idempotent par taskId : rappeler une tâche déjà supprimée renvoie encore 200, et purgedAt correspond à la première suppression, pas à cet appel. Vous pouvez réessayer sans risque après un délai dépassé.
• La réponse signifie « planifié », pas « déjà supprimé ». Tant que mediaDeletionPending vaut true, contentState vaut déjà purged, mais le nettoyage en arrière-plan n’a pas fini de retirer les objets ; il se termine normalement dans la minute. Une suppression synchrone permettrait à un objet récalcitrant de bloquer toute la requête, précisément au moment où vous avez besoin d’une réponse claire.
• Une réponse toujours à present signifie que cet appel n’a rien supprimé, par exemple si la tâche fait l’objet d’une obligation de conservation. Vous pouvez réessayer plus tard ; le motif précis n’est volontairement pas divulgué.
• billingRetained vaut toujours true. Ce champ paraît redondant, mais il précise le point le plus susceptible d’être mal compris dans ce point de terminaison ; voir ci-dessous.

contentState : présence du contenu et origine de sa suppression

Les détails d’une tâche incluent un contentState à trois valeurs :

Les deux dernières valeurs sont accompagnées de purgedAt, indiquant le moment de la suppression, et de contentRemovedBy : system pour le nettoyage, user pour votre action.

Afficher purged comme « expiré » est tout aussi trompeur : l’un résulte d’un bouton choisi par l’utilisateur, l’autre de l’application programmée de notre politique. Les inverser donne l’impression que la plateforme a perdu les fichiers.

L’expiration efface les champs, pas les enregistrements

Le nettoyage couvre input, output, les URL de callback ainsi que le contenu des événements et callbacks associés. L’enregistrement de la tâche est conservé sans limite de durée : c’est la preuve nécessaire à un litige de facturation, et le supprimer compromettrait la comptabilité. Chaque ligne ne contient alors que quelques centaines d’octets de métadonnées : identifiant de tâche, modèle, état, montant, horodatages et clé d’origine. La suppression à la demande suit exactement la même règle ; seul le moment est votre choix.

Après la disparition du contenu :

• Vous pouvez encore déterminer « combien ai-je payé ce mois-ci, quelles tâches ont échoué et quelle clé les a envoyées ? ».
• Vous ne pouvez plus déterminer « quel prompt ai-je envoyé, quelle clé d’objet contenait le fichier ? » : recordInfo ne renvoie plus input ni output.

Si vous avez besoin des prompts plus longtemps, conservez votre propre copie. Une obligation de conservation active suspend la suppression concernée et bloque aussi la suppression à la demande ; aucun de ces mécanismes ne peut restaurer un fichier déjà supprimé physiquement.

L’historique du solde est distinct du contenu des tâches

Effacer input et output, à l’expiration ou à votre demande, ne modifie ni les recharges, ni les réservations, règlements, restitutions ou ajustements manuels. Ces mouvements restent consultables pour vos rapprochements sur la page Facturation de la console. Les écritures du registre suivent une politique de conservation de dix ans et ne sont pas supprimées lorsque le contenu d’une tâche expire ou est effacé.

Si une demande d’accès ou de suppression concerne des données devant être conservées pour un litige, une enquête de sécurité ou la loi applicable, notre réponse en précisera le périmètre et le motif.

Deux engagements impossibles

L’exception : obligations de conservation légale

Les tâches concernées par un litige, une demande d’analyse forensique ou une obligation légale de signalement font l’objet d’une mesure de conservation : leur compte à rebours est suspendu jusqu’à la levée de cette mesure. La suppression à la demande ne s’exécute pas tant qu’elle est active.

Cette mesure prend le pas sur tous les délais et réglages ci-dessus. Ce n’est pas une exception cachée : sans mécanisme de conservation, la première injonction légale nous contraindrait à rompre un engagement de suppression, puis à expliquer pourquoi la documentation annonçait 14 jours. Elle est indiquée ici parce qu’elle fait partie de la politique.

Ce que vous pouvez faire

• Réglez chaque délai selon votre besoin réel. Ils sont indépendants : ne choisissez pas « Supprimer à la fin du traitement » pour les fichiers téléversés uniquement parce que vous souhaitez raccourcir la conservation des prompts.
• Téléchargez avant de raccourcir. Un délai plus court peut toucher des tâches déjà exécutées ; voir l’effet d’un changement de réglage.
• Utilisez X-Spicy-Retention pour une requête sensible ponctuelle. Il n’est pas nécessaire de reconfigurer tout le compte pour une seule génération.
• N’envoyez pas d’informations inutiles. Les images de référence et les prompts sont les deux éléments les plus sensibles, et les seuls dont vous choisissez le contenu.
• Archivez vos propres fichiers générés. Ils restent disponibles environ 14 jours au maximum, ou environ 60 jours pour les médias de courts-métrages, et moins si vous raccourcissez le délai.
• Copiez vos données de compte. Télécharger vos données, sur la page Protection des données, fournit un fichier JSON avec votre profil, vos rôles d’équipe, les détails des clés API, jamais leurs secrets, les données de tâches conservées et les enregistrements de facturation. Les médias ne sont pas inclus : téléchargez séparément les résultats à garder.
• Ne stockez pas les URL de téléchargement dans votre base de données. Elles expirent en 20 minutes et ne peuvent pas être révoquées après émission. Faites signer une URL au moment où vous en avez besoin ; voir Médias.
• Utilisez HTTPS pour les URL de callback. La charge utile contient l’état de la tâche et les références des fichiers ; en HTTP non chiffré, toute personne sur le trajet peut les lire.

Votre contenu ne sert pas à notre entraînement

Vos prompts, images de référence et fichiers générés ne sont intégrés à aucun jeu de données d’entraînement.

Le périmètre de cette phrase est essentiel : elle concerne SpicyAPI. Nous ne définissons pas les politiques de chaque modèle ; voir le premier point ci-dessus.