API Seedance 2.0 en 2026 : accès, tarification et routage de secours

L’API Seedance 2.0 n’est plus seulement une question de découverte de modèle. Pour les équipes produit, les questions plus difficiles sont de savoir si la route est disponible pour le mode d’entrée exact dont elles ont besoin, comment l’utilisation est facturée et ce qui se passe lorsqu’un modèle vidéo en aperçu ou en accès anticipé n’est pas disponible.

Cette distinction est importante car le paysage public des modèles évolue rapidement. ByteDance a officiellement lancé Seedance 2.0 le 12 février 2026, avec l’entrée multimodale et l’audio synchronisé comme capacités centrales. Au 27 juillet 2026, le répertoire public de modèles de Flatkey répertorie seedance-2.5 comme une option texte-vers-vidéo et image-vers-vidéo en accès anticipé en 1080p, tandis que seedance-2.0-i2v est répertorié comme une route image-vers-vidéo à l’usage en 720p.

Ces entrées de catalogue sont un point de départ utile, pas un contrat permanent. Une intégration en production doit vérifier la disponibilité du modèle, la modalité, la résolution, l’unité de tarification et la sémantique du job avant chaque lancement ou grande campagne.

Ce guide explique comment évaluer l’accès à Seedance en 2026, estimer le coût réel de la vidéo générée et concevoir un routage de secours qui ne casse pas lorsqu’un nom de modèle, une route de fournisseur ou une capacité change.

API Seedance 2.0 : la réponse courte

Les équipes qui évaluent l’API Seedance 2.0 doivent la considérer comme un workflow multimédia asynchrone avec un contrat de capacités versionné.

En pratique, cela signifie que votre application doit :

1. Valider si la route sélectionnée prend en charge le texte-vers-vidéo, l’image-vers-vidéo, l’audio, la résolution cible, la durée et la région.
2. Soumettre un job de génération au lieu d’attendre une réponse de type chat.
3. Stocker l’ID de job du fournisseur et votre propre clé d’idempotence.
4. Interroger périodiquement ou traiter un webhook jusqu’à ce que le job atteigne un état terminal.
5. Normaliser l’URL de sortie, les métadonnées, le coût et la raison de l’erreur.
6. Réessayer en toute sécurité ou sélectionner une route de secours compatible lorsque la route principale n’est pas disponible.

Si Seedance n’est qu’un modèle parmi d’autres dans un produit plus large, placez cette logique derrière une couche de routage plutôt que d’intégrer partout dans votre application les hypothèses d’un fournisseur.

Ce qui a changé depuis les premiers guides de l’API Seedance 2.0

Les premiers articles sur Seedance 2.0 se concentraient sur la recherche d’un chemin API utilisable, quel qu’il soit. Ce n’est plus suffisant.

La surface de décision actuelle comprend :

• Plusieurs versions de modèle : une équipe peut rencontrer Seedance 2.0, une route 2.0 spécifique à une modalité ou une route Seedance 2.5 plus récente.
• Différentes combinaisons de capacités : les limites de texte-vers-vidéo, d’image-vers-vidéo, de résolution, d’audio et de durée peuvent ne pas correspondre d’une route à l’autre.
• États d’accès changeants : l’accès anticipé, les listes d’autorisation, la disponibilité régionale et l’éligibilité du compte peuvent changer sans que votre produit change.
• Unités de facturation différentes : la tarification vidéo peut être exprimée par seconde, par élément généré, par crédit ou via une unité d’utilisation spécifique à la plateforme.
• Risque opérationnel asynchrone : le temps de file d’attente, les délais d’expiration, les soumissions en double, les URL de sortie expirantes et les jobs échoués affectent à la fois le coût et l’expérience utilisateur.

Le résultat est une question d’intégration plus mature : non pas « existe-t-il une API Seedance ? », mais « quelle route répond à cette demande aujourd’hui, et comment le produit se comportera-t-il si cette route cesse d’y répondre ? »

Instantané actuel de l’accès à Seedance au 27 juillet 2026

Le tableau suivant est une aide d’évaluation datée. Vérifiez le répertoire des modèles en direct avant l’implémentation, car l’accès et la tarification peuvent changer.

Route	État du catalogue public	Modalité	Sortie indiquée	Meilleure utilisation
seedance-2.5	Accès anticipé	Texte vers vidéo et image vers vidéo	1080p	Nouvelles évaluations qui ont besoin de l’ensemble de capacités actuel le plus large
seedance-2.0-i2v	À l’usage	Image vers vidéo	720p	Flux de travail image vers vidéo existants ou axés sur la compatibilité

Ce cliché met en évidence une règle de routage importante : un modèle plus récent n’est pas automatiquement un fallback valide pour chaque requête, et un modèle plus ancien n’est pas automatiquement interchangeable avec la route plus récente.

Un fallback valide doit satisfaire les capacités requises par la demande. Si l’utilisateur a fourni une image de référence, le fallback doit prendre en charge l’image vers vidéo. Si le produit promet une sortie en 1080p, une route limitée au 720p n’est pas équivalente. Si un audio synchronisé est requis, une route vidéo muette doit échouer à la validation des capacités avant soumission.

Accès direct au fournisseur versus passerelle API unifiée

Il existe deux façons courantes d’intégrer un modèle Seedance.

Intégration directe au fournisseur

L’accès direct peut être approprié lorsque :

• Seedance est le seul modèle vidéo dans le produit.
• Le compte du fournisseur est disponible dans la région d’exploitation de l’équipe.
• L’équipe est à l’aise avec la mise en œuvre de l’authentification propre au fournisseur, des états de tâches, des webhooks, de la facturation et des processus de support.
• Il n’y a pas d’exigence de changement de modèle sans publication côté client.

Le compromis est une dépendance opérationnelle. Les champs de requête, les codes d’erreur, la gestion des ressources et la logique de facturation spécifiques au fournisseur peuvent se propager dans le produit, à moins que l’équipe ne crée sa propre frontière d’adaptateur.

Intégration via une passerelle unifiée

Une passerelle est plus utile lorsque :

• La génération vidéo s’ajoute au chat, à l’image, à la voix ou aux charges de travail d’agent.
• L’équipe a besoin d’une seule clé et d’une seule surface de facturation sur plusieurs fournisseurs de modèles.
• La disponibilité des modèles ou l’accès régional peuvent changer.
• Le produit a besoin de quotas centralisés, de listes d’autorisation de modèles, de journaux d’utilisation ou de plafonds de dépenses.
• L’équipe veut modifier le routage des modèles sans réécrire chaque client.

Flatkey documente une couche d’accès stable, des plafonds par clé, des listes d’autorisation de modèles et la visibilité sur l’utilisation. L’avantage clé n’est pas seulement une configuration plus courte. C’est la capacité d’isoler un paysage fournisseur changeant derrière une seule frontière de routage contrôlée.

Consultez le guide de routage d’agent multimodal plus large pour le rôle architectural de cette frontière à travers les charges de travail vidéo, image, voix et texte.

Établir un contrat de capacités avant de choisir un modèle

Ne commencez pas la conception du fallback par une liste de noms de modèles. Commencez par un contrat de requête.

Un contrat interne illustratif pourrait ressembler à ceci :

{
  "operation": "image_to_video",
  "required": {
    "resolution": "1080p",
    "audio": true,
    "max_queue_seconds": 90
  },
  "preferred_models": [
    "seedance-2.5",
    "seedance-2.0-i2v"
  ],
  "fallback": {
    "allow_lower_resolution": false,
    "allow_silent_output": false,
    "max_attempts": 2
  }
}

Il ne s’agit pas du corps d’une requête fournisseur. C’est une politique au niveau de l’application que votre routeur peut évaluer avant de mapper la requête vers une API spécifique au fournisseur.

Le contrat devrait séparer :

• Exigences strictes : modalité, résolution minimale, audio, durée, région de conformité et format de sortie.
• Préférences : ordre des modèles, niveau de qualité, latence attendue et objectif de coût.
• Dégradation autorisée : si l’utilisateur accepte une résolution inférieure, une sortie silencieuse, une durée plus courte ou un style visuel différent.
• Limites opérationnelles : temps d’attente maximal dans la file, nombre de tentatives, budget et délai.

Sans cette séparation, le routage de secours devient de l’approximation.

Un workflow de routage de secours fiable

1. Maintenir un registre de routes en temps réel

Stockez chaque route candidate avec ses capacités et son état d’accès actuels :

• identifiant du modèle
• fournisseur
• modalités prises en charge
• limites de résolution et de durée
• prise en charge de l’audio
• restrictions régionales ou liées au compte
• unité de tarification
• état de santé actuel
• heure de la dernière requête réussie
• heure de la dernière actualisation des preuves

Ne supposez pas que le nom marketing du modèle contient suffisamment d’informations pour router en toute sécurité.

2. Filtrer par capacités avant l’état de santé

Supprimez d’abord les routes qui ne peuvent pas satisfaire la requête. Puis classez les routes restantes selon la santé, le coût, la latence ou la qualité.

Cet ordre empêche une route saine mais incompatible de recevoir une requête qu’elle ne peut pas exécuter.

3. Séparer l’échec à l’admission de l’échec du travail

Les API vidéo peuvent échouer avant ou après la création du travail.

Les échecs à l’admission incluent des identifiants invalides, des modèles indisponibles, des paramètres non pris en charge, des restrictions de compte et des limites de débit. Ceux-ci peuvent souvent déclencher un changement de route immédiat.

Les échecs du travail surviennent après qu’un fournisseur a accepté la requête. Ils peuvent impliquer un filtrage de sécurité, des erreurs de génération, des timeouts ou un échec de livraison d’asset. Relancer ces échecs demande plus de prudence, car la première tentative a peut-être déjà consommé du temps ou du calcul facturable.

4. Utiliser l’idempotence à votre frontière

Attribuez un ID de tâche applicative avant d’appeler un quelconque fournisseur. Stockez chaque tentative fournisseur sous cet ID.

Si le client réessaie à cause d’un timeout réseau, votre service devrait renvoyer l’état de la tâche existante plutôt que de soumettre à nouveau une génération identique. C’est particulièrement important pour les charges de travail vidéo, où les doublons accidentels peuvent être coûteux.

5. Normaliser les états des fournisseurs

Votre produit ne devrait pas exposer une machine d’état différente pour chaque modèle vidéo. Mappez les états spécifiques aux fournisseurs vers un petit ensemble interne tel que :

• queued
• running
• succeeded
• failed_retryable
• failed_terminal
• cancelled

Conservez l’état d’origine du fournisseur et l’erreur brute à des fins de débogage, mais gardez le contrat produit stable.

6. Appliquer des règles de repli limitées

Le fallback doit être délibéré, pas une boucle sans limite.

Une politique pratique pourrait autoriser :

• un chemin alternatif immédiat après un échec d’admission
• une tentative après un échec de tâche récupérable
• aucun fallback après un rejet de politique ou de sécurité
• aucune dégradation en dessous de la résolution ou de l’exigence audio explicitement choisie par l’utilisateur
• aucune nouvelle soumission une fois le budget ou la date limite de la demande épuisés

7. Enregistrez la décision d'itinéraire

Pour chaque tâche, enregistrez :

• les capacités demandées
• le chemin sélectionné et la raison
• les candidats rejetés et les raisons
• l’ID de tâche du fournisseur
• les horodatages de la file d’attente, du démarrage et de l’achèvement
• la durée et la résolution de sortie
• le montant facturé ou l’unité d’utilisation
• l’historique des tentatives et des fallbacks

Ces enregistrements transforment le routage d’une boîte noire en un système produit vérifiable.

Tarification de l'API Seedance 2.0 : vérifiez l'unité avant de comparer les chiffres

L’expression « Seedance 2.0 API pricing » peut masquer plusieurs modèles de facturation différents. Avant de comparer des fournisseurs ou des passerelles, vérifiez tout ce qui suit :

Pricing field	What to verify
Billing unit	Par seconde générée, par élément, par crédit, ou une autre unité d’utilisation
Resolution	Si le 720p et le 1080p ont des tarifs différents
Duration	Durée minimale, incréments et durée maximale
Audio	Si l’audio synchronisé modifie le tarif
Failed jobs	Si les générations échouées ou filtrées sont facturées
Retries	Si chaque nouvelle tâche chez le fournisseur est facturée séparément
Storage	Période de conservation de la sortie et coûts de téléchargement ou d’egress
Platform fee	Tout frais de passerelle, remise sur volume engagé ou tarif entreprise

Utilisez cette formule de charge de travail plutôt que de comparer un seul chiffre de titre :

monthly generation cost =
successful output seconds
× effective rate per second
+ retry and failure cost
+ storage and delivery cost
+ platform or support cost

Par exemple, un produit générant 10 000 clips réussis par mois peut avoir une économie très différente selon la durée moyenne, la résolution, le taux de reprise et l’inclusion ou non de l’audio. Une légère amélioration du taux de réussite au premier essai peut compter davantage qu’une petite différence dans le prix unitaire annoncé.

Utilisez la page de tarification Flatkey en direct pour les informations actuelles sur les offres et l’achat. Pour un déploiement sérieux, consignez la source de prix exacte et la date de vérification dans le même registre de routage qui stocke les capacités du modèle.

Migrer de Seedance 2.0 vers Seedance 2.5 sans casser le produit

Considérez une mise à niveau de modèle comme un changement de route contrôlé, et non comme un simple remplacement de chaîne.

Comparez les contrats

Testez si la nouvelle route préserve :

• types d’entrée et limites de taille
• comportement du prompt
• rapports hauteur/largeur pris en charge
• durée et résolution de sortie
• comportement de l’audio
• sémantique de l’état des tâches
• comportement de modération
• durée de vie des URL des actifs
• reporting des coûts

Exécuter une évaluation en shadow

Pour un petit échantillon de requêtes éligibles, soumettez la même entrée normalisée aux deux routes en dehors du chemin critique du client. Comparez le taux d’achèvement, la latence, la qualité de sortie, le coût et les ফলats de politique.

Utiliser un déploiement progressif

Transférez un petit pourcentage des tâches compatibles vers la route la plus récente. Conservez l’ancienne route disponible uniquement là où elle satisfait encore l’intégralité du contrat de requête.

Préserver l’observabilité au niveau des routes

Ne regroupez pas les métriques de Seedance 2.0 et Seedance 2.5 dans un total unique « vidéo ». Suivez les versions séparément afin qu’un déploiement ne masque pas les régressions.

Erreurs courantes d’intégration de l’API Seedance

Traiter la génération vidéo comme une complétion de chat

Les tâches vidéo de longue durée ont besoin d’un état durable, d’une gestion de file d’attente et de la gestion des actifs. Un schéma de requête synchrone crée des délais d’attente fragiles et un mauvais comportement de reprise.

Utiliser les noms de modèle comme politique de repli

seedance-2.5 et seedance-2.0-i2v ne sont pas interchangeables simplement parce qu’ils partagent un nom de famille. Acheminez selon les capacités.

Réessayer sans idempotence

Un délai d’attente côté client ne prouve pas que le fournisseur a rejeté la requête. Des reprises aveugles peuvent créer des tâches facturables en double.

Promettre une résolution que le repli ne peut pas produire

Si le produit promet du 1080p, une route 720p ne devrait pas prendre le relais silencieusement. Demandez le consentement de l’utilisateur ou échouez clairement.

Copier un prix non daté dans la logique produit

Les pages de tarification changent. Enregistrez la source tarifaire et la date vérifiée, puis rendez le seuil de coût configurable.

Ignorer la conservation de sortie

Les URL du fournisseur peuvent expirer. Copiez les actifs terminés dans votre propre stockage approuvé avant d’exposer une URL produit durable.

Checklist de mise à jour pour un guide émergent sur les modèles vidéo

Les pages sur les modèles émergents devraient avoir un responsable de mise à jour explicite et un cycle de preuves. Révisez cette page chaque fois qu’une version majeure de Seedance est lancée, et au moins chaque mois tant que l’accès évolue rapidement.

Chaque mise à jour devrait vérifier :

1. Annonce officielle du modèle/de la version.
2. Identifiant actuel du modèle dans le catalogue en direct.
3. Prise en charge du texte vers vidéo et de l’image vers vidéo.
4. Limites de résolution, de durée, d’audio et de région.
5. État d’accès, y compris l’accès anticipé ou les exigences de liste d’autorisation.
6. Unité de tarification actuelle et page d’achat.
7. Sémantique de création de tâche, de sondage, de webhook et d’annulation.
8. Comportement de reprise, de facturation des échecs et de conservation de sortie.
9. État public de la route et affirmations datées de l’article.
10. Liens internes vers la tarification et les conseils de routage multimodal.

C’est la différence entre un article qui se classe brièvement et un actif qui reste utile tant que la demande de recherche est encore en formation.

Foire aux questions

Existe-t-il une API Seedance 2.0 ?

Oui. Seedance 2.0 est une version officielle du modèle vidéo de ByteDance, et l’accès à l’API est disponible via les routes fournisseur et passerelle. L’identifiant exact du modèle, la modalité, la région et l’éligibilité du compte dépendent du chemin d’accès, donc vérifiez le catalogue en direct avant l’implémentation.

La API Seedance 2.0 prend-elle en charge le texte en vidéo et l’image en vidéo ?

Seedance est une famille de modèles vidéo multimodaux, mais les routes API individuelles peuvent être spécifiques à une modalité. Au 27 juillet 2026, Flatkey répertorie seedance-2.0-i2v pour l’image en vidéo et répertorie seedance-2.5 pour le texte en vidéo et l’image en vidéo.

Combien coûte la API Seedance 2.0 ?

La réponse dépend du fournisseur, de la route, de la résolution, de la durée, du mode audio et de l’unité de facturation. Vérifiez si la route facture à la seconde, à l’asset, au crédit ou selon une autre unité d’utilisation, puis incluez les tentatives, les échecs, le stockage et les frais de plateforme dans l’estimation de la charge de travail.

Seedance 2.5 peut-il servir de solution de secours pour Seedance 2.0 ?

Il peut être un candidat lorsqu’il satisfait à la même modalité requise, à la même résolution, au même audio, à la même région, au même budget et au même contrat opérationnel. Ne le considérez pas comme un remplacement automatique basé uniquement sur le nom de la famille de modèles.

Qu’est-ce qui devrait déclencher une route de secours ?

De bons déclencheurs incluent l’indisponibilité de la route, les restrictions de compte, les limites de débit et les échecs d’infrastructure pouvant être retentés. Les refus liés à la sécurité, les capacités non prises en charge, les budgets épuisés et les délais expirés devraient normalement arrêter le traitement plutôt que déclencher une génération alternative incontrôlée.

L’étape suivante pratique

Avant de choisir une route Seedance, notez les capacités que votre produit promet et les dégradations qu’il peut autoriser. Vérifiez ensuite le catalogue de modèles en direct et la source de tarification, exécutez un petit test de tâche asynchrone et consignez la date des preuves.

Si Seedance doit coexister avec d’autres modèles vidéo, d’image ou de langage, conservez les détails du fournisseur derrière une couche de routage stable. Cela donne à votre équipe un moyen contrôlé d’adopter des modèles plus récents, de préserver les options de secours et d’actualiser les hypothèses d’accès sans reconstruire le produit à chaque changement du paysage des modèles.