Nouvelles tentatives d’API d’images IA NSFW : éviter de payer deux fois la même image

Votre application de personnages adultes promet une nouvelle image. Le client appuie sur Générer, l’indicateur tourne un moment, puis la page indique que la connexion a expiré. Il appuie à nouveau. Une minute plus tard, deux images apparaissent et le solde a baissé deux fois.

La deuxième peut être très belle. Cela reste une façon coûteuse de découvrir qu’une expiration de connexion n’est pas un échec de génération.

Pour une API d’images NSFW, « réessayer » désigne trois actions différentes : vérifier une tâche existante, rejouer sa soumission initiale et payer une nouvelle tentative créative. Séparez-les. Avec un identifiant de tâche, vérifiez cette tâche. Si la réponse de création a disparu, rejouez la requête inchangée avec sa clé d’idempotence d’origine. Si la tâche est terminée mais que l’image manque le brief, une autre génération est un nouvel achat.

Cette dernière distinction compte particulièrement pour l’imagerie de personnages adultes. Un modèle peut terminer en atténuant la scène, en changeant la tenue ou en produisant un autre visage. La réussite de la tâche indique qu’un résultat a été livré, pas que vous voudrez l’utiliser.

Que s’est-il passé, et quel bouton proposer ?

Attendre, récupérer une soumission et créer une variation sont des actions différentes.

Une interface utile pourrait nommer ces actions Vérifier l’image existante, Récupérer la soumission, Générer une autre variation et Réessayer le téléchargement. Un unique bouton Réessayer cache la différence entre une consultation gratuite d’état et l’autorisation d’une nouvelle dépense.

Si vous avez un identifiant, gardez la tâche originale

Le workflow asynchrone de SpicyAPI accepte une requête, renvoie un identifiant et rend l’image disponible plus tard. Une réponse de création acceptée n’est pas l’image terminée. La tâche passe par des états comme queued, running et succeeded ; failed, canceled et expired sont également des états finaux.

Enregistrez l’identifiant dès sa réception par votre serveur, avant de mettre à jour le navigateur. Si le client actualise, se reconnecte ou ouvre le projet sur un autre appareil, l’application doit reprendre cette tâche enregistrée plutôt que soumettre à nouveau le prompt.

Par exemple, un créateur demande un nouveau portrait du soir de son personnage adulte fictif. Le serveur reçoit l’identifiant, mais le navigateur perd la connexion avant d’afficher la carte d’attente. Au retour, cette carte doit reprendre le suivi de la tâche. Actualiser une page n’est pas demander un deuxième portrait.

Utilisez GET /api/v1/jobs/recordInfo avec l’identifiant pour retrouver l’état actuel. La documentation des tâches décrit requête et réponse. Un webhook peut annoncer l’achèvement, mais un webhook retardé ne transforme pas la tâche en échec. Le polling reste une voie de récupération.

Ne transformez pas une limite d’attente locale en décision de facturation. Le navigateur peut cesser d’attendre après 30 secondes, la requête HTTP sortante du serveur après 60 secondes, tandis que la tâche distante continue. L’enregistrement renvoyé comprend une échéance d’exécution, deadlineAt, qui concerne l’exécution distante, pas la durée de connexion de la page. L’expiration du lien de téléchargement est encore une autre horloge.

Pour l’écran d’attente, utilisez un message comme « Votre image est toujours en cours de traitement. Vous pouvez quitter cette page et retrouver la même tâche. » Ne promettez pas un délai précis sans mesures pour le modèle et la charge concernés. La latence mesurée par un concurrent sur des images de produits ordinaires n’est pas une garantie pour vos prompts NSFW.

Si la réponse de création est perdue, rejouez la même soumission

Le cas difficile est une connexion coupée après l’envoi par le serveur, mais avant l’accusé de réception. Cette erreur de connexion ne permet pas de savoir si la plateforme a accepté la tâche.

SpicyAPI offre une véritable protection côté serveur : l’en-tête facultatif Idempotency-Key. Pour le même compte et la même clé API, répéter une clé avec les mêmes modèle normalisé, entrée et URL de callback dans les 24 heures renvoie la tâche d’origine sans réserver à nouveau des fonds. Une requête modifiée entre en conflit avec cette clé. Une autre clé API du même compte ne peut pas non plus rejouer sa correspondance ; elle reçoit un conflit sans divulgation de l’identifiant original.

Créez une clé stable pour l’image demandée, pas pour chaque tentative HTTP. Une valeur d’application comme project-8-image-12-v1 illustre ce principe. N’y mettez ni détails personnels ni texte brut du prompt. Générez-la et sauvegardez-la avant la première création. Une nouvelle tentative réseau la réutilise ; une image réellement nouvelle reçoit une nouvelle version ou un nouvel identifiant d’opération.

La séquence minimale de récupération est :

1. Enregistrer dans l’application l’opération prévue, le corps de requête original et sa clé.
2. Soumettre cette requête avec Idempotency-Key.
3. Si l’accusé est perdu, marquer l’opération locale en attente de confirmation.
4. Rejouer le corps et la clé d’idempotence inchangés, avec la même clé API.
5. Enregistrer l’identifiant renvoyé et passer au suivi de son état.

Gardez stable la requête réellement soumise pendant la récupération. Ne la reconstruisez pas depuis des commandes que le client a pu modifier. Passer d’un portrait serré à une composition large, augmenter la résolution, modifier le prompt ou l’URL de callback signifie qu’il ne s’agit plus de la soumission originale.

La protection a une limite : 24 heures ne constituent pas un stockage indéfini de prévention des doublons. Après ce délai, ne supposez pas que l’ancienne clé retrouvera l’ancienne tâche. Votre correspondance durable opération-tâche doit gérer les retours ultérieurs. Si l’acceptation reste incertaine et la tâche introuvable, rapprochez les enregistrements du compte ou demandez au support avant de créer automatiquement un remplacement.

Désactiver Générer aide, mais ne suffit pas

Un bouton désactivé pendant le chargement empêche un double appui courant. Il n’empêche pas les soumissions depuis deux onglets, un mobile qui se reconnecte, un worker de fond ou un serveur redémarré.

L’application doit rattacher ces événements à une seule opération logique d’image. Une contrainte d’unicité dans votre base empêche deux workers de prendre indépendamment la même opération. La clé d’idempotence protège ensuite la création distante. Ce sont des protections différentes ; les deux sont nécessaires si plusieurs chemins soumettent les tâches.

Prenons un produit de compagnon qui génère un portrait facultatif après une conversation. L’utilisateur appuie aussi sur le bouton manuel avant l’accusé de la demande automatique. Si les deux actions doivent satisfaire la même demande de portrait, reliez-les à une opération. Si le bouton manuel demande explicitement une deuxième variation, présentez-la comme une autre génération payante. Ne fusionnez pas silencieusement deux achats voulus, et ne facturez pas discrètement deux fois une seule promesse.

La clé ne décide pas de ces règles produit. L’application définit ce qui compte comme même demande. Une ligne dédupliquée localement n’aide pas non plus si le client sortant utilise une nouvelle clé distante à chaque récupération. La valeur doit survivre à tout le parcours.

Refus, échec technique et image indésirable ont des factures différentes

Une requête adulte peut se terminer de plusieurs manières. Évitez de promettre que tous les échecs NSFW sont gratuits, et n’affirmez pas non plus que toute erreur est facturée.

État de tâche et satisfaction créative diffèrent. Vérifiez l’enregistrement régularisé et les exceptions tarifaires du modèle.

SpicyAPI réserve un montant estimé lors de l’acceptation. Tant que settled vaut false, cost est l’estimation réservée. Après régularisation, il représente le montant final. Une tâche réussie est facturée dans la limite de la réservation ; les fonds inutilisés sont libérés.

Une tâche échouée ou expirée libère normalement sa réservation. La politique de remboursement décrit des exceptions, notamment les modèles dont la page indique la facturation des requêtes refusées ou échouées, et l’usage déjà livré avant une interruption. Pour une image refusée par le modèle, vérifiez sa note tarifaire et l’enregistrement final régularisé. Ne fondez pas l’explication du solde sur la seule erreur HTTP.

Une image réussie mais atténuée est différente. Imaginez un personnage adulte fictif assuré dans une scène éditoriale adulte précise, mais un résultat réduit à un portrait conventionnel. Si la tâche réussit et livre sa sortie, l’insatisfaction ne transforme pas celle-ci en échec technique remboursable. Il en va de même pour une mauvaise coiffure, un accessoire indésirable ou une expression déplaisante.

C’est pourquoi une politique de reprise utile demande une limite de dépense créative, pas seulement un nombre de tentatives réseau. Un worker qui relance toutes les images déplaisantes peut continuer à acheter des sorties réussies longtemps après la résolution des problèmes techniques.

Lisez la page du modèle exact pour votre tâche. Une route texte vers image permissive ne prouve pas un comportement identique en édition, et le nom de famille ne prédit pas chaque requête NSFW. Utilisez uniquement des adultes et des ressources que vous avez le droit de soumettre ; réessayer ne rend pas une demande interdite acceptable.

Réessayer un échec final crée une nouvelle tâche

L’API propose aussi POST /api/v1/jobs/retry, qui reçoit l’identifiant source et crée une nouvelle tâche à partir d’un échec final admissible. Elle ne remet pas l’ancienne tâche en cours. Entrées actuelles, permissions, disponibilité, solde et prix sont réévalués. La source doit encore avoir ses entrées conservées et sa facturation rapprochée ; une tâche active ou réussie n’est pas admissible.

Utilisez la même clé API que pour la source. Si vous appliquez une clé d’idempotence à la reprise, elle protège cette nouvelle tentative précise et son périmètre est lié à la tâche source. Rejouer cette action peut retrouver la nouvelle tâche ; c’est différent de rejouer la création initiale pour retrouver l’originale.

Dans une application de création, présentez cela comme une nouvelle tentative de génération avec son prix. Si le prompt doit changer, créez une nouvelle requête révisée plutôt que d’attendre cette modification de la reprise par identifiant. Un échec causé par une référence expirée demande également une référence valide. La libération du montant initial et la réservation du nouvel essai sont deux écritures séparées.

Ce que coûtent vraiment les essais répétés

Voici des configurations initiales actuelles pour trois endpoints d’images. Les tarifs décrivent la génération, sans garantir que chaque résultat respecte un brief NSFW.

Exemple de planification hypothétique : les doublons accidentels ajoutent $2.40 à $7.20 d’essais créatifs intentionnels.

Les détails comptent. Z-Image Turbo avec expansion coûte $0.016 par image plutôt que $0.010. Seedream 5.0 Pro utilise 2K par défaut, à $0.072 plutôt que $0.036 en 1K. Sélectionner explicitement le palier fait correspondre le calcul à la tâche.

Supposons 100 portraits finaux Qwen Image 2.1 en 1K. Si chaque image demande en moyenne trois essais créatifs facturés, la dépense est $7.20 : 100 × 3 × $0.024. Si un bug d’accusé duplique aussi une soumission par image finale, il ajoute 100 × $0.024 = $2.40, pour $9.60 au total. Ces chiffres sont des exemples, pas un taux de réussite mesuré.

Modifier le délai HTTP ne transforme pas un processus créatif de trois essais en un seul. Vous pouvez supprimer le quatrième essai accidentel. Séparez variations intentionnelles et doublons accidentels dans vos totaux pour voir le problème réellement payé.

Pour un petit workflow, fixez la limite avant génération : par exemple une image initiale et deux essais révisés pour cet emplacement. C’est une suggestion de budget d’application, pas une limite de plateforme. Si les trois manquent la même exigence, cessez d’acheter des requêtes quasi identiques et changez d’approche.

Une image NSFW terminée manque le brief : changez un élément déterminant

Si le visage convient mais pas la pièce ou la tenue, une édition ciblée peut être un meilleur achat qu’une nouvelle génération complète. Gardez le résultat utile, décrivez le changement et choisissez une tâche d’édition appropriée. L’édition coûte encore de l’argent ; ce n’est pas une correction gratuite incluse dans la première génération.

Si la même requête produit toujours une scène atténuée, cherchez d’abord s’il s’agit d’un refus de contenu, d’une demande permise interprétée prudemment ou d’un prompt surchargé. Renvoyer sans cesse le même texte ne le dit pas. Examinez l’image et le code d’erreur stable éventuel plutôt que de prendre NSFW pour un interrupteur universel.

Dans un exemple non explicite, un brief demande un adulte fictif, une veste sombre en satin, une pose assise, un éclairage latéral chaud et une pièce sobre. Si tous les résultats montrent une pièce encombrée, retirez les détails secondaires de décor en gardant personnage et éclairage. Si le visage est incorrect, passez à un workflow avec référence au lieu d’ajouter des adjectifs au prompt textuel.

Pour une véritable nouvelle variation, utilisez une nouvelle opération et une nouvelle clé. Rejouer la demande acceptée avec sa clé originale retrouve la première tâche ; cela ne demande pas une meilleure deuxième image. Un seed modifié pour une variation doit être enregistré comme nouvel essai créatif. Il identifie la requête sans garantir le même personnage entre modèles.

Après les premiers essais, comparez le coût par image utile, pas seulement le tarif initial affiché. Une génération à $0.010 utilisée quatre fois coûte $0.040. Une génération à $0.024 utilisée une fois coûte $0.024. Ce calcul ne prouve pas la fiabilité supérieure du deuxième modèle ; il indique quoi mesurer avec votre brief.

Quand une image existante ne se télécharge pas

Ne régénérez pas une image réussie à cause d’une erreur de téléchargement. Le fichier peut exister même si son lien temporaire ne fonctionne plus, ou votre application peut avoir échoué pendant la copie.

Conservez la tâche terminée et l’identité du visuel. Retrouvez une voie de téléchargement autorisée actuelle tant que la sortie est conservée, puis relancez le transfert. N’ajoutez pas la clé API à une URL média signée séparée. Confirmez que les octets existent réellement dans la destination avant d’afficher Enregistré dans la bibliothèque du client.

Le guide de livraison des médias explique la copie dans votre stockage. Pour un créateur adulte, c’est aussi une frontière de confidentialité : une image ou référence ne devient pas publique simplement parce que la copie a réussi. La récupération doit garder les accès privés prévus.

Si la sortie a déjà été supprimée selon la politique de rétention effective de la tâche, son identifiant ne restaure pas les octets absents. Un remplacement serait une nouvelle génération, potentiellement différente. Expliquez-le au client au lieu de remplacer silencieusement l’ancien portrait par un nouveau facturé.

Faites correspondre l’action suivante du client au montant facturé

Affichez ensemble l’état de la tâche et son montant régularisé. Si elle reste non résolue, gardez sa place dans le projet sans présenter une nouvelle tentative payante comme seule solution. Si elle échoue, montrez la cause et la libération éventuelle des fonds. Si elle réussit, distinguez Télécharger à nouveau de Générer une autre variation.

Pour le support, les éléments utiles sont l’identifiant de tâche, l’identifiant de requête lorsqu’il existe, l’horodatage, le montant et une courte description. Deux identifiants de tâche différents ne sont pas la même chose qu’une seule tâche débitée deux fois. La politique de remboursement demande de signaler les doubles débits, les montants supérieurs à la réservation, les sorties réussies non livrées ou les réservations d’échec non rendues sous 24 heures. N’incluez pas de clés API, liens média signés ou prompts sensibles dans les journaux ordinaires ou captures de support.

Le créateur doit pouvoir lire l’historique comme « un portrait demandé, une soumission récupérée, un résultat livré », plutôt que comme une liste de tentatives HTTP invisibles. Voilà l’objectif : la récupération réseau conserve l’achat original, tandis qu’un autre essai créatif reste une décision volontaire au prix visible.