Skip to main content

Démarrage rapide

Le point de terminaison image natif est synchrone par défaut. Définissez le booléen async sur true pour créer une tâche en arrière-plan. Cet exemple utilise qwen-image-2.0.

Comment découvrir les modèles média asynchrones et obtenir leurs schémas ?

La découverte se déroule en deux étapes. Récupérez d’abord dans le catalogue public les modèles texte-image ou texte-vidéo compatibles avec les API asynchrones. Utilisez ensuite le model_id du modèle pour obtenir le schéma de requête de ses endpoints.

Lister les modèles compatibles avec les API asynchrones

Le catalogue de modèles utilise la même source de données que Playground. Utilisez type=image_generation pour les modèles texte-image et type=video pour les modèles texte-vidéo. Le paramètre schema_checked=true limite la liste aux modèles dont le schéma de requête a été publié et vérifié.
Les deux requêtes utilisent le même endpoint. Le filtre type accepte actuellement une seule valeur. Interrogez donc chaque type de modèle séparément. La réponse suit la forme {success, message, data}. Les champs de data utiles aux intégrations média asynchrones sont les suivants.

Obtenir le schéma de requête d’un modèle

Les champs, les valeurs d’énumération et les plages numériques pris en charge peuvent varier selon le modèle. Avant d’envoyer une requête d’image ou de vidéo, utilisez l’endpoint public ci-dessous pour récupérer les endpoints disponibles et les schémas JSON de requête du modèle sélectionné.
La valeur modality de la réponse est image ou video. Chaque élément du tableau endpoints décrit un protocole d’appel disponible. Un modèle peut renvoyer des endpoints /ai/v1 ainsi que des endpoints /v1 compatibles avec OpenAI. Les endpoints compatibles avec OpenAI peuvent ne pas encore prendre en charge les modèles les plus récents. Utilisez donc de préférence les endpoints /ai/v1. Pour les API de tâches asynchrones, sélectionnez l’élément dont le path est /ai/v1/images/generations ou /ai/v1/videos, puis utilisez son request.schema. Ne dépendez pas de la position d’un élément dans le tableau endpoints. Les commandes suivantes extraient directement le schéma de requête de chaque endpoint de tâche asynchrone.
L’endpoint renvoie 404 model_not_found si le modèle n’existe pas ou ne dispose d’aucun endpoint détectable. Il renvoie 500 endpoints_unavailable lorsque les données des endpoints sont temporairement indisponibles.

Comment créer une tâche d’image ?

Image synchrone

Lorsque async est omis ou vaut false, l’API attend la fin de la génération et renvoie l’objet tâche :
Les tâches d’image synchrones sont également enregistrées. Si la connexion du client est interrompue ou si la réponse de création est perdue, utilisez GET /ai/v1/images pour retrouver la tâche.

Image asynchrone

Lorsque async vaut le booléen true, l’API renvoie immédiatement l’objet tâche et la génération se poursuit en arrière-plan :
Consultez la tâche avec GET /ai/v1/images/{id}. Une fois terminée, demandez directement le content_url de chaque élément output. Cette URL contient le result_id de l’image correspondante.
Dans une requête d’image, async doit être un booléen. webhook_url et webhook_events_filter ne peuvent être utilisés qu’avec async: true.

Champs standard des images


Objet de tâche média

Les API propres aux images et aux vidéos renvoient la structure suivante :
Élément output d’un média :

Description des statuts

Le client peut interroger la tâche toutes les 15 secondes jusqu’au statut completed, failed ou cancelled. Cet intervalle de 15 secondes est une recommandation pour le polling côté client, pas une restriction du protocole serveur.

Comment consulter les tâches média ?

Consulter le détail d’un média

Les API de détail média peuvent renvoyer un statut actualisé. Utilisez donc l’API de détail d’image ou de vidéo correspondante pour le polling.

Lister les médias

Si la réponse de création est perdue, retrouvez l’ID de tâche dans la liste du média correspondant :
La liste média renvoie un instantané au moment de la consultation et n’actualise pas activement le statut des tâches.

Comment utiliser l’API de tâches unifiées ?

L’API de tâches unifiées accepte les filtres suivants :
Détail d’une tâche unifiée :
Élément output unifié d’une tâche média :
Pour un résultat unique, demandez directement /ai/v1/tasks/{id}/content. Pour plusieurs résultats, demandez /ai/v1/tasks/{id}/content/{result_id}. Sans ID de résultat, l’API renvoie 400 result_id_required.
Les API de liste, de détail et de contenu des tâches unifiées sont isolées selon le Bearer Token qui a créé la tâche. Une autre clé API du même compte ne peut pas lire cette tâche.

Télécharger les résultats média

Télécharger des images

Une fois l’image terminée, demandez chaque output[].content_url de l’objet de tâche média :
Le chemin de téléchargement média d’une image est /ai/v1/images/{id}/content/{result_id}. L’objet de tâche média n’expose pas result_id séparément. Le client peut utiliser directement content_url. Lorsque b64_json n’est pas vide, décodez directement ce champ en Base64.

Utiliser un Webhook

Les images asynchrones et les vidéos prennent en charge les Webhooks au niveau de la tâche :
webhook_url est limité à 512 caractères et ne peut pas pointer vers la machine locale, un réseau privé ou une autre adresse restreinte. Lorsque webhook_events_filter est omis, la plateforme envoie completed, failed et cancelled. Lorsqu’il est fourni, le tableau ne peut pas être vide ni contenir de doublons, et doit être utilisé avec webhook_url. Si webhook_url est absent de la requête, les images asynchrones et les vidéos tentent d’utiliser l’adresse de rappel par défaut du compte. Une adresse par défaut non valide est ignorée et ne bloque pas la création de la tâche.

Requête de rappel

results n’apparaît que si le résultat a été archivé. Le téléchargement nécessite toujours un Bearer Token.

Nouvelles tentatives et déduplication

La plateforme utilise une livraison au moins une fois. Un même événement peut être envoyé plusieurs fois :
  • HTTP 2xx indique une réception réussie.
  • HTTP 5xx, une erreur réseau ou un délai dépassé déclenchent une nouvelle tentative.
  • HTTP 3xx et 4xx ne déclenchent pas de nouvelle tentative.
  • Six livraisons au maximum, avec des intervalles successifs de 1, 4, 16, 64 et 256 secondes.
Le destinataire doit enregistrer event_id et renvoyer immédiatement 2xx s’il reçoit à nouveau le même événement.
Le Webhook au niveau de la tâche n’a pas de clé de signature indépendante. Si une vérification de signature est nécessaire, configurez un abonnement Webhook au niveau du compte et conservez la consultation du détail de la tâche comme méthode de confirmation du résultat.

Réponses et codes d’erreur

Cette section s’applique à /ai/v1/images/* et aux tâches d’image. Pour les erreurs vidéo, consultez l’API vidéo. Les colonnes message ci-dessous contiennent les messages de réponse en anglais. Les descriptions en expliquent le sens et le traitement. Les erreurs de validation des paramètres présentent un message générique ; la réponse réelle peut préciser les champs et contraintes concernés. Les clients doivent identifier le type d’erreur à partir de code, sans dépendre d’une correspondance avec le message complet.

Signaler une erreur HTTP 5xx

Lorsqu’une requête renvoie HTTP 5xx, signalez le problème en joignant error.tid.

Échecs des requêtes HTTP

Les statuts HTTP ci-dessous s’appliquent à l’échec direct de la requête en cours. Pour les échecs d’exécution après la création d’une tâche, consultez le tableau Échecs d’exécution des tâches ci-dessous.

Paramètres de requête et médias d’entrée

Limites de taille
  • Taille du média : les tâches d’image dépassant la limite renvoient image_too_large. La limite exacte figure dans le message d’erreur ou dans error.details.max_bytes.
  • Taille totale de la requête : request_too_large signifie que le corps HTTP dépasse 32 MiB, y compris le texte, les paramètres et l’encodage des médias intégrés. Lorsqu’une URL seule est fournie, elle compte dans la taille du corps ; le fichier qu’elle désigne doit aussi respecter les limites de média du modèle.
  • Taille réelle : error.details.actual_bytes est fourni uniquement lorsque la taille complète est confirmée. Lors de la lecture d’un média par URL, ce champ peut être absent si la lecture s’arrête à la limite.
Formats pris en charge Les formats dépendent du modèle choisi. Consultez d’abord error.details.allowed_mime_types ou la liste de formats du message d’erreur. En l’absence de liste, consultez le Schema du modèle. Variables dans les messages
  • {media_kind} : le type réel de média. Lorsque ce type est confirmé, les messages de invalid_media_data et media_url_unreachable utilisent également image ou video.
  • {max_bytes} : la limite en octets. Si la limite de l’image est inconnue, la réponse est The image is too large. Reduce the image size and try again.
  • {allowed_formats} : la liste des formats autorisés. Les messages d’erreur de format peuvent ajouter Use one of: {allowed_formats}.

Requêtes de génération et résultats renvoyés

Compte et autorisations

Disponibilité du service et limites de débit

provider_unavailable indique une défaillance du fournisseur de modèles explicitement identifiée. Un simple statut 429 ou 4xx ne permet pas de confirmer un problème de quota, de modération du contenu ou de paramètres.

Consultation des tâches et téléchargement des résultats

Échecs d’exécution des tâches

Après la création réussie d’une tâche, un échec de génération est signalé par status=failed et le champ error de la tâche. Une consultation réussie renvoie toujours HTTP 200.
Les erreurs de média d’entrée peuvent aussi apparaître dans les tâches en échec. Leurs codes gardent le sens indiqué dans le tableau des médias d’entrée ci-dessus ; les consultations réussies renvoient toujours HTTP 200. Pour les erreurs de taille de média, le message se termine par submit a new task., afin d’indiquer de réduire le média avant de soumettre une nouvelle tâche. output_blocked indique un blocage explicite sans image exploitable renvoyée ; aucun frais de génération n’est facturé pour cette tentative. Les règles existantes de facturation de la modération s’appliquent à output_policy_violation. Consultez l’historique de facturation pour les frais antérieurs.

Échecs de lecture des résultats individuels d’une liste

Certaines lignes des listes de tâches d’image et de vidéo peuvent comporter output_error :
Ce champ indique que le résultat de cette ligne n’a pas pu être lu pour la requête en cours. La liste renvoie toujours HTTP 200, avec output=[] pour cette ligne. Ses champs id, status et error ainsi que la pagination restent inchangés, et les autres tâches lisibles ne sont pas affectées. Même avec status=completed, vérifiez output_error avant de déterminer si le résultat peut être lu. Contactez l’assistance avec output_error.tid. Si ce champ ne contient pas de tid, fournissez l’ID de requête des en-têtes de la réponse en cours. Cette erreur ne modifie ni le statut de la tâche ni les frais, et ne déclenche pas de Webhook. Les listes d’images et de vidéos conservent la valeur expires_at déjà obtenue. Dans la liste unifiée /ai/v1/tasks, les lignes dont le résultat n’a pas pu être lu peuvent renvoyer expires_at=null ; la durée de conservation initiale continue de s’appliquer. Ce traitement s’applique uniquement lorsqu’un résultat individuel est illisible et qu’aucune solution de repli n’est disponible. L’échec de consultation de tout un lot dans l’API de tâches unifiées renvoie toujours une erreur HTTP ; le même type d’échec lors de la lecture des détails renvoie toujours HTTP 500. Documentation associée : API image · API vidéo · Tâches asynchrones

Exemple complet

Ces exemples créent une tâche asynchrone, l’interrogent et enregistrent chaque image retournée.