Traitement batch
Traiter efficacement plusieurs générations lipsync
L’API Batch de Sync Labs traite jusqu’à 500 générations de lip sync dans une seule requête, envoyées sous forme de fichier JSONL ou de tableau JSON de lignes. C’est idéal pour les workflows de traitement vidéo en masse, comme les campagnes vidéo personnalisées, la localisation de contenu, ou tout scénario qui exige une génération de lip sync à grand volume.
Quel est le format de fichier batch ?
Le traitement batch vous permet d’envoyer 20 à 500 générations sans gérer vous-même la file d’attente ni la concurrence, avec un délai cible de 24 heures. Les jobs batch contournent votre limite de concurrence normale par génération, mais l’API Batch n’est disponible que sur le plan Scale ou supérieur. À ce jour, seules les générations avec des entrées allant jusqu’à 30 secondes sont prises en charge en traitement batch.
L’API Batch nécessite le plan Scale ou supérieur, y compris Enterprise
Limites de concurrence batch
Les jobs batch contournent votre limite de concurrence normale par génération, mais une limite séparée plafonne le nombre de batchs que vous pouvez exécuter en même temps, selon votre plan. Si vous envoyez un nouveau batch alors que vous êtes déjà à cette limite, l’API renvoie une réponse 429 Too Many Requests.
Le corps de la 429 est un objet JSON qui décrit la limite atteinte :
La réponse inclut aussi un en-tête Retry-After (en secondes) et un en-tête X-Sync-Concurrency-Limit. Plutôt que de réessayer immédiatement, attendez retryAfterSeconds avant de renvoyer, ou attendez qu’un de vos batchs en cours se termine.
Comment créer un job batch ?
Préparer votre fichier d'entrée
Créez un fichier JSON Lines (.jsonl) avec vos requêtes de génération. Chaque ligne doit contenir un request_id unique, l’endpoint (doit être "/v2/generate"), et un payload avec le format standard de requête de génération (identique à celui de la API de génération). Le fichier doit être au format JSON Lines (.jsonl) avec un minimum de 20 enregistrements, une taille maximale de 5MB, et jusqu’à 500 requêtes par batch.
Créer un batch
Au lieu de téléverser un fichier, vous pouvez envoyer un corps application/json avec les enregistrements dans rows. Chaque ligne de rows est le même objet qu’une ligne JSONL, et les deux formes sont validées de la même façon : 20 à 500 lignes par défaut, 5 MB maximum une fois écrites en JSONL, et des valeurs request_id uniques. Quand un enregistrement est refusé, l’erreur indique sa ligne. Les refus d’édition de dialogue la renvoient dans un champ lineNumber ; les autres erreurs d’enregistrement, comme un JSON invalide ou un request_id manquant, ne l’indiquent que dans message (par exemple Record at line 4: payload is required). Les lignes comptent les enregistrements non vides, pas les lignes physiques : les lignes vides d’un fichier JSONL sont ignorées ; avec un corps JSON, la ligne N correspond à rows[N-1]. Les exemples ci-dessus montrent deux enregistrements par souci de concision ; un batch en nécessite au moins 20.
Paramètres optionnels :
webhook_url: Recevoir des notifications quand le batch est terminédry_run: Définirtruepour valider votre entrée sans lancer le traitement. Une entrée valide renvoie{"status": "VALIDATED"}et ne crée aucun batch.
La création de batch n’est pas couverte par les requêtes idempotentes. Si une requête de création expire, listez vos batchs avec GET /v2/batch avant de renvoyer la requête, afin de ne pas exécuter deux fois les mêmes lignes.
Vérifier le statut du batch
Suivez la progression de votre batch en interrogeant son statut :
Un batch peut avoir l’un des statuts suivants :
PENDING: Batch créé, en attente de démarrage du traitementPROCESSING: Les générations sont en cours de traitementCOMPLETED: Toutes les générations sont terminées (avec succès ou échec)FAILED: Le traitement batch a totalement échoué
Vérifier les résultats du batch
Quand un batch se termine, les résultats sont disponibles sous forme de fichier JSON Lines à l’adresse outputUrl de la réponse get batch. Un GET vers cette URL renvoie une redirection 302 vers un fichier de résultats signé, les clients qui suivent automatiquement les redirections peuvent lire directement la réponse JSONL. Chaque ligne contient :
Le champ response contient les mêmes données que les réponses individuelles de la API de génération. Les noms de champs du fichier de résultats sont en snake_case : la vidéo d’une ligne terminée se trouve donc à response.output_url et son ID de génération à response.id. Associez chaque ligne à votre entrée grâce à request_id.
Pour un exemple complet et fonctionnel, consultez l’exemple de traitement batch dans notre dépôt d’exemples.
Notifications webhook
Lorsque vous fournissez un webhook_url, vous recevrez des notifications POST à la fin du batch :
Le webhook de fin de batch peut être livré plusieurs fois pour un même batch. Utilisez l’id du batch pour ignorer les notifications que vous avez déjà traitées.
Lignes d’édition de dialogue (accès anticipé)
Une ligne de batch peut produire le rendu d’un aperçu d’édition de dialogue terminé, au lieu d’associer une vidéo à un nouvel audio. Utilisez-la pour transformer une vidéo enregistrée en de nombreuses variantes, par exemple une par nom de destinataire. Le tutoriel Messages vidéo personnalisés propose un script complet.
Les lignes d’édition de dialogue sont en accès anticipé et s’activent par organisation. Contactez-nous pour les activer. D’ici là, les lignes qui contiennent dialogueEdit sont refusées à l’envoi.
Le payload de chaque ligne contient :
model, par exemplesync-3.inputavec exactement une vidéo : la même vidéo source que celle à partir de laquelle l’aperçu a été créé.dialogueEdit: {"id": "..."}: l’ID d’un aperçu terminé issu dePOST /v2/dialogue-editsdans votre organisation.
N’ajoutez pas d’entrées audio ou texte, ni segments, ni dubParams ; l’aperçu fournit l’audio.
Les mêmes objets de ligne fonctionnent aussi comme lignes d’un fichier JSONL téléversé.
À l’envoi, chaque ligne d’édition de dialogue est développée exactement en la requête que POST /v2/generate construit pour cet aperçu, et elle est facturée comme cette génération. Le payload du fichier de résultats montre la requête développée (la vidéo, l’audio de l’aperçu et les segments modifiés), et non la ligne que vous avez envoyée. Envoyez d’abord le batch avec dry_run: true : il exécute toutes les vérifications ci-dessous, y compris le développement, sans effectuer aucun rendu.
- Toutes les lignes d’édition de dialogue d’un même batch doivent utiliser des aperçus créés à partir de la même vidéo source. Pour plusieurs vidéos, envoyez un batch par vidéo.
- Les limites habituelles des batchs s’appliquent : 20 à 500 lignes et 5 MB.
- La plupart des aperçus sont rendus sous forme de segments modifiés de la vidéo. Un aperçu qui ne peut être rendu qu’en lip sync sur la vidéo entière n’est accepté dans un batch que si ce rendu dure 30 secondes ou moins ; générez les plus longs avec
POST /v2/generate.
Refus des lignes d’édition de dialogue
Si une ligne d’édition de dialogue ne peut pas être rendue, toute la requête est refusée et aucun batch n’est créé. La réponse contient l’errorCode que POST /v2/generate renverrait pour cet aperçu, ainsi que le lineNumber de la première ligne en échec :
Seule la première ligne en échec est signalée. Corrigez-la et relancez le dry run jusqu’à ce qu’il renvoie {"status": "VALIDATED"}.
Ressources associées
- Rate Limits — comprendre le rate limiting API pour planifier efficacement vos tailles de batch
- Webhooks Guide — configurer les notifications webhook pour les événements de fin de batch
- gestion des erreurs — référence des codes d’erreur spécifiques au batch et dépannage

