Démarrage rapide

Choisissez un modèle et un endpoint dans le Catalog, puis envoyez les entrées requises par l’endpoint. Cet exemple démarre une tâche Flux 2 de texte vers image :

Une requête asynchrone acceptée renvoie 202 Accepted avec un identifiant de tâche :

Stockez id avec votre enregistrement applicatif. C’est l’identifiant stable utilisé pour l’interrogation, le support et la réconciliation des callbacks.

Les Media Input Fields sont les champs de requête qui contiennent des URL de médias : les champs de premier niveau dont le nom se termine par _url ou _urls, comme image_url ou image_urls, l’url de chaque élément de video_list, ainsi que element_input_urls, element_input_video_urls et element_input_audio_urls de chaque élément de kling_elements. callback_url est un endpoint de livraison, pas un Media Input Field. Chaque valeur d’un Media Input Field peut être une URL HTTPS publique ou une data URI au format data:<mime>;base64,<data>, jusqu’à 10 Mo par data URI. RunAPI enregistre chaque data URI comme File Upload temporaire qui expire au bout d’une heure et utilise cet upload pour la Task. Une data URI qui ne peut pas être enregistrée renvoie 422 avec le code d’erreur invalid_media_input.

Les endpoints d’édition GPT Image n’acceptent que des URL HTTPS dans source_image_urls. Pour envoyer une image locale à ces endpoints, créez d’abord un File Upload et transmettez l’URL renvoyée.

Pour les fichiers de plus de 10 Mo, créez d’abord un File Upload avec POST /api/v1/files et transmettez l’URL renvoyée. Un File Upload multipart ou à partir d’une URL accepte des fichiers jusqu’à 50 Mo. Les URL de File Upload expirent aussi au bout d’une heure : créez un nouveau File Upload pour chaque Task qui démarre après ce délai.

Les endpoints de création de tâche acceptent un en-tête optionnel Idempotency-Key avec une valeur opaque pouvant aller jusqu’à 512 caractères. Générez une valeur par tâche logique et conservez-la avec la requête jusqu’à ce que vous sachiez si elle a été acceptée.

Si un délai d’attente ou une panne de connexion laisse le résultat inconnu, réessayez la même requête de création de tâche avec la même clé. RunAPI retourne la tâche originale au lieu d’en créer une nouvelle et de la facturer. La réutilisation d’une clé avec une requête de création de tâche différente retourne 409 Conflict. Générez une nouvelle clé pour une nouvelle tâche intentionnelle, et n’utilisez pas X-Client-Request-Id comme clé.

Les endpoints synchrones lents maintiennent normalement la connexion ouverte et retournent la même réponse terminale qu’auparavant. Aucune modification d’interrogation n’est requise pour les intégrations existantes.

Pour un budget de connexion intentionnellement plus court, envoyez Prefer: wait=N. Si la tâche est toujours en cours après ce budget explicite, RunAPI renvoie 202 Accepted avec le même id de tâche, une URL Location opaque pour la récupération, et Retry-After pour le délai de requête suggéré. Suivez Location exactement plutôt que de construire une URL de résultat. Un résultat de tâche terminée préserve le statut HTTP terminal, les en-têtes autorisés, le type de contenu et le corps ; décodez response.body selon response.content_type, qui n’est pas toujours JSON.

Ajoutez l’identifiant de tâche au même chemin de point de terminaison :

Continuez tant que status est processing. Utilisez un backoff borné entre les requêtes plutôt qu’une interrogation continue. Une tâche devient terminale lorsque son statut est completed ou failed.

Une réponse completed inclut l’id de la Task, le status terminal, les champs de résultat spécifiques au point de terminaison, et usage.cost sous forme de montant float USD pour cette Task. Conservez le résultat dont vous avez besoin et arrêtez l’interrogation. Consultez la référence API du point de terminaison pour connaître la forme exacte du résultat plutôt que de supposer que chaque point de terminaison multimédia renvoie les mêmes champs.

Les enveloppes de Task de création, processing et failed omettent usage.

Les tâches nécessitant une facturation définitive fondée sur les médias restent à l’état processing jusqu’à l’enregistrement de leur montant final. Le rappel de fin de tâche n’est envoyé qu’après cette facturation ; sa valeur usage.cost correspond à celle des requêtes ultérieures portant sur la tâche. Les données comptables manquantes ne sont pas indiquées comme nulles : la tâche reste à l’état processing pendant leur rapprochement. Un montant nul confirmé est renvoyé sous la forme usage.cost: 0.

Une réponse failed inclut l’id de la tâche, le status terminal et un error fourni par RunAPI lorsqu’il est disponible. Arrêtez l’interrogation, enregistrez l’identifiant et l’erreur, et ne réessayez que lorsque votre application a classifié l’échec comme transitoire. Une nouvelle tentative crée un nouvel identifiant de tâche.

Ajoutez un callback_url HTTPS public à la requête de création lorsque vous souhaitez que RunAPI envoie les événements de rappel documentés pour ce point de terminaison :

Chaque corps de rappel correspond à un événement de cycle de vie dans la référence API du point de terminaison. Un rappel completed partage usage.cost avec la réponse d’interrogation completed ; les rappels de création, processing et failed omettent usage. Les rappels terminaux incluent les mêmes champs de résultat que les réponses d’interrogation terminales ; certains points de terminaison envoient également des rappels processing documentés. Renvoyez rapidement une réponse HTTP réussie et gardez l’interrogation disponible pour la réconciliation en cas de retard de livraison ou d’indisponibilité de votre gestionnaire de rappels.

Lisez Callbacks pour créer un secret de callback, vérifier les signatures et gérer les nouvelles tentatives en toute sécurité.

UtilisezPOST /api/v1/vidu/image_to_videoavecmodel: "vidu-q4-image-to-video"etfirst_frame_image_url. UtilisezPOST /api/v1/vidu/reference_to_videoavecmodel: "vidu-q4-reference-to-video", unpromptnon vide et 1 à 15reference_image_urlsordonnés. Récupérez chaque tâche avecGETsur son chemin de création suivi de/:id. Les tâches terminées contiennent un tableauvideosd’URL de résultats. Vous pouvez également fournircallback_urlpour les notifications d’achèvement.

Les deux points de terminaison acceptent l’entierduration_secondsde 3 à 16, 5 par défaut, etoutput_resolutionde540p,720p,1080p,2kou4k, par défaut.720p.audioest un booléen JSON, par défauttrue; explicitefalsedésactive l’audio généré. Les invites acceptent jusqu’à 20 000 caractères. L’invite image-vidéo est facultative et la première image détermine son rapport hauteur/largeur. La référence à la vidéo accepteaspect_ratiode16:9,9:16,1:1,4:3ou3:4, par défaut16:9et jusqu’à 3reference_audio_urls.

Utilisez les URL des médias publicsHTTP(S). Les images doivent êtreJPG/JPEG,PNGouWEBP; l’image de la première image ne doit pas dépasser 50 Mo. Chaque fichier audio de référence doit êtreMP3, durer de 3 à 12 secondes et ne pas dépasser 50 Mo.RunAPIvérifie les types de champs, les schémas d’URL et le nombre de références. Le fournisseur de génération vérifie le format, la taille et la durée du média distant de manière asynchrone. Un support non valide peut entraîner l’échec de la tâche via le flux normal d’échec et de remboursement.

Tarifs image vers vidéo. Tarifs références vers vidéo.