Aller au contenu principal

Celebrity Look-Alike prend un portrait et renvoie une image générée de la célébrité la plus ressemblante, sans prompt ni paramètre. La photo doit montrer un seul visage net, à peu près de face, et le résultat n’affiche ni nom ni score.

À partir de $0.05/image

Atelier

Entrée

Édition d’image
1/1

Déposez des fichiers ou des liens de médias, collez ou parcourez · 1 fichier · 10 Mo max. · JPG · PNG · WEBP · GIF

  • 1
1 / 1 fichiers
Un portrait net, à peu près de face, avec un seul visage visible. Photos de groupe, profils, lunettes de soleil et flou de bougé sont les cas où la correspondance se dégrade ou l’appel échoue. N’envoyez que des photos de personnes ayant consenti à cet usage. 1 caractères minimum
Filtre de sécuritéDésactivé

SpicyAPI n’applique aucun filtre de sécurité à ce modèle. Votre prompt et vos médias sont transmis tels quels, et c’est le modèle lui-même qui décide du résultat.

Nous vérifions votre compte avant d’activer l’envoi et le calcul du prix.

Sortie

Prêt pour une nouvelle exécution
passport-frontal-maleRendu d’exemple

Modèles liés et tâches suivantes

Le modèle que vous cherchez n’est pas là ?

Dites-nous lequel ajouter et à quoi il vous servira. Les demandes vont directement à l’équipe qui décide des prochains modèles.

Un seul champ image, aucun paramètre, une image générée en retour

L’API d’édition de Celebrity Look-Alike prend un seul portrait dans image_url et renvoie une image générée de la célébrité la plus ressemblante. Ce champ constitue la totalité du corps de la requête : pas de prompt, pas de graine, pas de résolution, pas de format de sortie. additionalProperties vaut false, donc toute autre clé échoue à la validation. La réponse ne contient que l’image : ni nom, ni liste de candidats, ni score de ressemblance.

Ouvrir le Playground
Corps de la requête
image_url (chaîne, obligatoire) constitue tout le corps : une propriété, sans prompt, graine, résolution ni format de sortie
URL d’entrée
Doit mener directement au fichier image, s’ouvrir sans connexion et rester valide jusqu’à la fin de la tâche
Réponse
Une image générée. Ni nom de célébrité, ni liste de candidats, ni score de ressemblance
Mode d’appel
Asynchrone : envoyer, garder l’identifiant de tâche, interroger jusqu’à l’état final. Plafond de 1 800 secondes
Conservation
La photo envoyée est supprimée au bout d’1 jour, le résultat généré au bout de 14 jours
Consentement
Chaque entrée est le visage d’une personne réelle. N’envoyez que des portraits dont la personne a accepté l’usage
Schéma
Une propriété, et toute autre clé est une erreur de validationLe schéma de requête définit image_url et met additionalProperties à false. Une chaîne de prompt oubliée, ou une valeur d’intensité recopiée depuis la charge utile d’un autre endpoint, revient sous forme d’erreur de validation nommant le champ en cause, et aucune tâche n’en naît. Rien n’est mis en file d’attente, et rien n’est silencieusement écarté en chemin.
Réponse
L’absence de nom et de score est un choixIl n’y a derrière cet endpoint aucune étape de classification dont nous pourrions transmettre l’étiquette : il fabrique une image, il ne cherche personne dans une liste. La réponse ne porte donc ni nom de célébrité, ni classement, ni indice de confiance. Le libellé affiché par votre interface, c’est vous qui l’écrivez et vous qui l’assumez.
Consentement
À chaque appel, l’entrée est le visage d’une personne réelleRien d’autre n’est sensible dans cette requête : la photo l’est. En pratique, la seule source sûre est le portrait de l’utilisateur lui-même, pris dans votre produit, pour cette fonctionnalité, avec un consentement recueilli avant que le fichier n’atteigne votre stockage. Au moment de décider si vous avez le droit de l’utiliser, appliquez la même exigence qu’à la reconnaissance faciale, même si cet endpoint ne reconnaît personne.

Ce que l’API Celebrity Look-Alike fait bien

  • Tout le corps de la requête tient en un champ

    image_url est obligatoire, rien d’autre n’est accepté, et la liste s’arrête là. Aucun gabarit à produire, aucune table de champs dynamique à maintenir : une variable de type chaîne posée dans un objet JSON couvre tous les appels que cet endpoint recevra un jour, que la photo soit un selfie pris au téléphone ou un portrait de studio.

  • Quand il n’y a rien à régler, on ne peut rien mal régler

    Pas de prompt à écrire, pas de graine à figer, pas de résolution ni de format de sortie à choisir. Le seul levier disponible est la photo elle-même. Quand un résultat déçoit, la réponse est donc une autre prise de vue, cadrage plus serré, lumière plus homogène, visage plus franchement face à l’objectif, et non un balayage de paramètres qui n’existent pas.

  • Un visage par requête, par construction

    Cet endpoint prend un portrait et n’a aucun moyen d’apprendre quelle personne du cadre vous visiez. Une photo de groupe n’est donc pas une entrée difficile, c’est une entrée fausse. Recadrer sur un seul visage avant l’envoi supprime la cause la plus fréquente d’un résultat que personne autour de la table ne valide.

  • Une tâche, une image

    Une tâche terminée expose une seule image générée depuis le stockage de la plateforme, et aucun champ ne permet d’en demander davantage. Dix portraits, ce sont dix tâches, chacune avec son identifiant, son état d’interrogation et sa facturation : une photo inexploitable ne bloque donc pas les neuf autres.

  • Asynchrone, avec un plafond de 1 800 secondes

    L’envoi répond par un identifiant de tâche plutôt que par une image, et vous lisez cette tâche jusqu’à ce qu’elle annonce un état final. Il n’existe pas de mode synchrone de repli. Une tâche qui n’atteint jamais d’état final ne reste pas ouverte indéfiniment : elle est close au plafond de 1 800 secondes de cet endpoint.

  • Deux horloges de conservation à intégrer

    La photo envoyée est supprimée au bout d’1 jour et le résultat généré au bout de 14 jours. Aucun de ces deux chiffres n’est un obstacle à contourner : ils expliquent pourquoi il faut rapatrier au passage dans votre stockage une image que vous voulez garder, et pourquoi une carte de partage ne peut pas pointer indéfiniment vers notre URL.

À qui Celebrity Look-Alike s’adresse

  • Équipes produit grand public

    Une fonctionnalité qui ne demande rien d’autre qu’une photo

    Aucun champ de prompt à concevoir, aucun sélecteur de style à expliquer, et aucun cas d’échec où quelqu’un saisit quelque chose d’inutilisable. Le parcours se résume à envoyer, attendre, voir une image. C’est pour cela que toute la fonctionnalité tient derrière un bouton et un espace réservé, et pour cela que le vrai travail de conception est l’écran de consentement qui la précède.

  • Intégration côté serveur

    Un schéma assez petit pour être écrit en dur plutôt que généré depuis un gabarit

    Avec une seule chaîne à remplir, le corps de la requête n’a besoin ni d’un registre de champs, ni d’un générateur de formulaire piloté par le schéma, ni d’une couche de validation maison. Reste la plomberie : une URL qui mène à des octets, une clé d’idempotence à la création, une boucle d’interrogation et une copie avant la fin de la fenêtre de conservation.

  • Revue juridique et protection des données

    Une décision qui se prend avant la mise en ligne, pas après

    Les données biométriques font l’objet d’une réglementation distincte et stricte dans l’Union européenne et dans plusieurs États américains, et cette obligation vous revient, pas à nous. Réglez d’abord trois points par écrit : où le consentement est recueilli, combien de temps la photo reste de votre côté, et qui répond du texte affiché à côté du résultat.

  • Équipes qui greffent cela sur un envoi existant

    Où les nouvelles obligations retombent dans une chaîne que vous exploitez déjà

    Si des portraits circulent déjà dans votre produit, l’ajout de l’endpoint lui-même est un petit travail : le poids est ailleurs. Le consentement doit être recueilli avant que le fichier n’atteigne votre stockage, car il ne se rattrape pas après coup. Et nos délais d’1 jour et de 14 jours ne remplacent en rien votre propre politique de conservation.

Comment appeler l’API Celebrity Look-Alike

  1. Recueillir le consentement avant que la photo n’existe dans votre stockage

    Le consentement se situe une étape avant l’URL, et il ne se rattrape pas. Décidez à quoi la personne consent, consignez son accord et gardez cette trace rattachée à la photo. C’est cette étape qui détermine si le reste de l’intégration a le droit de tourner.

  2. Préparer une URL qui renvoie le fichier image lui-même

    image_url est une chaîne : le lien doit donc mener directement aux octets de l’image et s’ouvrir sans connexion. Une page dans laquelle la photo est intégrée n’est pas une photo. Si votre stockage distribue des URL signées à durée courte, vérifiez au moment de l’envoi que le lien est encore valide et gardez-le vivant jusqu’à la fin de la tâche.

  3. Envoyer le corps à un champ avec une clé d’idempotence

    Construisez le corps à partir d’image_url seul et retirez ce qui traîne de la charge utile d’un autre endpoint, puisque additionalProperties vaut false. Joignez-y un Idempotency-Key : si la connexion tombe et que votre client rejoue la requête, la clé renvoie la tâche d’origine plutôt qu’une seconde assortie d’une seconde facturation.

  4. Interroger l’identifiant de tâche jusqu’à l’état final

    La réponse à l’envoi ne contient rien d’autre que l’identifiant : lisez donc la tâche jusqu’à ce qu’elle annonce un état final. N’immobilisez pas une requête utilisateur pour attendre, renvoyez un espace réservé au navigateur et remplissez-le quand la lecture aboutit. Le plafond de 1 800 secondes donne la borne extérieure de la boucle.

  5. Recopier l’image, puis écrire la légende vous-même

    L’URL du résultat pointe vers le stockage de la plateforme, et ce fichier est supprimé au bout de 14 jours : rapatriez au passage dans votre propre espace tout ce qui est destiné à une galerie ou à une carte de partage. La réponse ne contient rien qui permette d’étiqueter l’image, donc chaque mot posé à côté est une affirmation que vous formulez.

Celebrity Look-Alike en pratique

  • Une fonctionnalité à un seul bouton dans une application grand public

    L’utilisateur prend son portrait dans l’application, coche un consentement qui dit exactement à quoi la photo servira, et le client la dépose dans votre propre espace de stockage. Votre backend envoie un champ, affiche un espace réservé, puis y glisse l’image dès que l’interrogation aboutit. Paramètres exposés à l’utilisateur : aucun.

  • Une file de portraits qui survit à une coupure de connexion

    Un traitement par lots envoie une tâche par portrait et joint à chacune un Idempotency-Key dérivé de l’identifiant de la photo stockée. Si un envoi est interrompu et que le traitement rejoue la requête, la clé renvoie la tâche d’origine plutôt qu’une seconde : un lot redémarré ne paie donc pas deux fois pour une photo déjà envoyée.

  • Une galerie qui survit à la fenêtre de 14 jours

    Un produit où les utilisateurs reviennent sur leurs résultats passés ne peut pas pointer vers nos URL d’assets, puisque ces fichiers sont supprimés au bout de 14 jours. La forme qui tient est une étape de copie dans le worker même qui gère l’interrogation finale : récupérer une fois, déposer dans votre propre espace, enregistrer votre URL et ne plus jamais lire la nôtre.

Questions sur l’API Celebrity Look-Alike

Il n’y a pas de prompt à écrire ni de paramètre à régler : toute l’intégration se joue sur les entrées, la plomberie et l’autorisation. Réglez le consentement avant que la photo n’arrive dans votre stockage, c’est la seule étape qui ne se répare pas ensuite. Préparez une URL qui renvoie les octets de l’image et reste valide jusqu’à la fin de la tâche. Envoyez le champ unique avec un Idempotency-Key, interrogez l’identifiant de tâche jusqu’à l’état final, et recopiez avant la fin des 14 jours tout ce que vous comptez garder. Écrivez ensuite la légende : la réponse vous remet une image et, délibérément, rien pour la nommer.