API Seedance pour les équipes produit texte-vers-vidéo

Si votre équipe produit souhaite la manière la plus rapide et la plus sûre d’évaluer l’accès à Seedance API, la bonne première étape n’est pas de construire dès le premier jour le workflow vidéo complet. Il s’agit de prouver trois bases avec la plus petite surface d’intégration possible :

1. votre clé Flatkey s’authentifie correctement
2. votre application peut appeler https://router.flatkey.ai/v1
3. votre équipe peut voir la requête dans les journaux d’utilisation avant de brancher les tâches vidéo asynchrones

C’est ce quickstart à faible friction que cette page couvre.

À la date du vendredi 17 juillet 2026, le quickstart public de Flatkey indique toujours aux développeurs d’utiliser l’authentification Bearer, l’URL de base compatible OpenAI https://router.flatkey.ai/v1 et POST /v1/chat/completions pour le premier test de fumée. Le catalogue de modèles en ligne de Flatkey répertorie également publiquement seedance-2.5 pour le texte-vers-vidéo ainsi que l’image-vers-vidéo, et seedance-2.0-i2v pour l’image-vers-vidéo. La page d’API publique de Seedance décrit toujours le workflow vidéo comme une création de tâche asynchrone, interrogation du statut, webhooks et crédits basés sur l’utilisation.

Cette combinaison compte pour l’onboarding : le schéma d’accès au routeur est simple, mais le workflow réel de génération vidéo n’est pas un appel de chat synchrone. Les équipes produit devraient d’abord valider le routeur avec la plus petite requête possible, puis remplacer uniquement le modèle et le flux de tâche nécessaires à l’évaluation de Seedance.

Réponse rapide

Utilisez cette séquence lorsque vous voulez un parcours d’onboarding Seedance examinable avec le moins d’éléments mobiles possible.

Étape	À utiliser	Ce que cela prouve
1. Créer une clé	Clé API Flatkey commençant par sk-fk-	Votre équipe dispose d’un identifiant valide
2. Définir une seule URL de base	https://router.flatkey.ai/v1	Votre application pointe vers le routeur partagé, et non vers un point de terminaison spécifique à un fournisseur
3. Exécuter le plus petit test de fumée	POST /v1/chat/completions avec un modèle texte simple	L’authentification, les en-têtes, le routage et les journaux d’utilisation fonctionnent
4. Basculer vers la route Seedance	Remplacer le modèle temporaire par l’ID de modèle Seedance approuvé	La même couche d’accès peut désormais prendre en charge votre workflow d’évaluation vidéo
5. Ajouter la gestion asynchrone	Logique de polling ou de webhook pour les tâches vidéo	Votre produit est prêt pour une exécution réelle du texte-vers-vidéo

Si vous ne devez retenir qu’une seule chose, retenez ceci : la première requête cURL est un contrôle de connectivité du routeur, pas le payload final texte-vers-vidéo.

Avant de commencer

Vous avez besoin de quatre éléments :

• Un compte Flatkey
• Une clé API Flatkey
• Un certain crédit prépayé pour la requête
• Une décision produit sur la route Seedance que vous souhaitez réellement évaluer

Pour la plupart des équipes texte-vers-vidéo, le catalogue public de modèles rend les choix actuels suffisamment lisibles pour lancer la discussion :

Signal public actuel du modèle sur Flatkey	Meilleure utilisation
seedance-2.5	Évaluation texte-vers-vidéo, plus image-vers-vidéo si nécessaire
seedance-2.0-i2v	Image-vers-vidéo uniquement

Ne codez pas en dur un nom de modèle provenant d’une vieille capture d’écran ou d’une note interne. Vérifiez le répertoire de modèles actuel ou le catalogue en direct le jour de la publication, car la disponibilité des routes vidéo peut changer plus vite qu’un guide de configuration statique.

Étape 1 : créer et enregistrer la clé API Flatkey

Dans la console Flatkey, créez une clé API et enregistrez-la comme variable d’environnement.

export FLATKEY_API_KEY="sk-fk-..."

C’est le premier endroit où les équipes créent une friction évitable. Gardez la clé côté serveur, pas dans le code du navigateur ni dans une note locale partagée. Si l’évaluation concerne une équipe produit plutôt qu’un seul ingénieur, utilisez dès le départ un secret détenu par l’équipe.

Étape 2 : exécuter le plus petit test de fumée possible du routeur

Le quickstart actuel de Flatkey utilise POST /v1/chat/completions pour la première requête. C’est le bon choix même si votre objectif final est la génération vidéo Seedance, car cela vérifie la couche d’accès partagée avant d’ajouter la complexité d’un workflow asynchrone.

curl https://router.flatkey.ai/v1/chat/completions   -H "Authorization: Bearer $FLATKEY_API_KEY"   -H "Content-Type: application/json"   -d '{
    "model": "gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Répondez avec le mot connected."}
    ]
  }'

Une réponse réussie vous indique immédiatement cinq choses utiles :

• la clé API est valide
• l’en-tête Authorization: Bearer ... est correct
• l’URL de base est correcte
• votre client peut envoyer un POST JSON avec succès
• la requête doit apparaître dans les journaux d’utilisation Flatkey avec les comptes de jetons et le coût

C’est la plus petite preuve vérifiable que la couche d’accès fonctionne.

Étape 3 : comprendre ce que la requête de test de fumée vérifie réellement

Le test de fumée chat-completions est volontairement simple. La structure requise est :

Champ de requête	Pourquoi c’est important
Authorization header	Confirme le format du jeton Bearer
Content-Type: application/json	Confirme que le corps de la requête est analysé correctement
model	Confirme que la route peut résoudre un ID de modèle
messages	Confirme que le corps correspond au schéma compatible OpenAI

La documentation actuelle de chat-completions de Flatkey met aussi en avant les trois champs de réponse que les équipes produit examinent généralement en premier :

• choices[0].message.content
• model
• usage

Ce dernier champ est particulièrement utile pour l’onboarding, car il offre aux équipes produit et opérations un endroit commun pour vérifier que la requête est bien passée par le routeur.

Étape 4 : remplacer le modèle temporaire par l’évaluation Seedance

Une fois le test de fumée réussi, conservez les mêmes identifiants et la même URL de base du routeur, puis ne changez que les éléments spécifiques à votre workflow vidéo.

Conservez inchangés :

• Authorization: Bearer $FLATKEY_API_KEY
• https://router.flatkey.ai/v1
• votre gestion des secrets côté serveur
• votre chemin de revue des journaux et de la facturation

Modifiez ensuite ces éléments :

Ce qui change après le smoke test	Pourquoi cela change
model	Vous remplacez le modèle texte fictif par l’ID du modèle Seedance approuvé
Structure du corps de la requête	La génération vidéo a besoin de ses propres champs de charge utile, pas seulement d’un tableau messages de type chat
Gestion de la réponse	Les workflows vidéo renvoient l’état du job, des assets ou un statut asynchrone plutôt qu’un texte immédiat uniquement
Logique produit	Vous devez utiliser du polling ou un webhook au lieu de traiter l’appel comme un chat synchrone

Pour une évaluation produit texte-vers-vidéo, l’espace réservé sûr le jour de la mise en production est :

seedance-2.5

Pour une évaluation image-vers-vidéo, la route publique actuelle est :

seedance-2.0-i2v

Utilisez ces noms comme point de départ pour l’exploration, et non comme une promesse que chaque workflow en aval partage une structure de charge utile identique.

Étape 5 : concevez autour du workflow vidéo asynchrone de Seedance

C’est l’étape que la plupart des quickstarts omettent.

La page de l’API publique de Seedance décrit toujours le workflow comme :

• création de tâche asynchrone
• polling du statut
• webhooks
• crédits basés sur l’utilisation

Cela signifie qu’une équipe produit devrait supposer que le véritable chemin vidéo nécessite au moins quatre états dans sa propre application :

État du job	Ce que votre application doit faire
queued	Enregistrer le job et afficher que la requête a été acceptée
running	Interroger le statut ou attendre un webhook
succeeded	Récupérer l’asset de sortie et associer les métadonnées
failed	Enregistrer l’erreur et décider s’il faut réessayer

Si votre équipe essaie de traiter Seedance comme une réponse de chat synchrone, l’intégration semblera instable même lorsque l’API fonctionne normalement.

Une séquence d’intégration pratique pour les équipes produit

Si vous voulez la boucle d’évaluation la plus courte possible, utilisez cet ordre :

1. Créez la clé Flatkey.
2. Exécutez le smoke test chat/completions.
3. Vérifiez que la requête apparaît dans les journaux d’utilisation.
4. Choisissez l’ID du modèle Seedance actuel que vous voulez réellement tester.
5. Implémentez le flux de requête asynchrone spécifique à Seedance.
6. Ajoutez un chemin de polling ou un chemin de webhook avant d’élargir le déploiement.

Cela réduit le risque d’intégration, car vous séparez la vérification du routeur de l’implémentation du workflow vidéo.

Dépannage

401 ou 403 dès la première requête cURL

Signifie généralement que la clé est invalide, expirée ou qu’elle n’est pas transmise en tant que jeton Bearer.

Vérifiez :

• que la clé commence par sk-fk-
• que la variable shell est bien définie
• que l’en-tête est Authorization: Bearer ...

404 ou mismatch de route

Signifie généralement que votre application pointe vers la mauvaise URL.

Utilisez :

https://router.flatkey.ai/v1

Ne pointez pas la requête vers le site marketing et ne supprimez pas le suffixe /v1.

La requête réussit mais les journaux d’utilisation restent vides

Le guide de démarrage rapide de Flatkey indique explicitement d’attendre quelques secondes puis de relancer la recherche. Si les logs n’apparaissent toujours pas, revérifiez le nom du modèle, la clé API et l’URL de base que vous avez réellement envoyés.

Le test de fumée fonctionne mais le workflow Seedance ne fonctionne pas

Cela signifie généralement que la couche d’accès est correcte et que le problème se situe désormais à l’un de ces endroits :

• mauvais ID de modèle Seedance
• mauvaise forme de charge utile vidéo
• logique de polling asynchrone manquante
• gestion des webhooks pas encore implémentée
• code produit qui suppose une réponse texte synchrone

C’est un progrès, pas un échec. Vous avez déjà isolé le problème en dehors de l’authentification et du routage.

Quand ce guide de démarrage rapide suffit

Ce guide de démarrage rapide suffit lorsque votre équipe a besoin de répondre à :

• Pouvons-nous nous authentifier via Flatkey ?
• Pouvons-nous réutiliser notre chemin client compatible OpenAI ?
• Le produit et l’exploitation peuvent-ils voir la requête dans les logs ?
• Pouvons-nous passer d’un test de fumée texte à une route Seedance sans ajouter d’abord une autre clé fournisseur ?

Si la réponse à ces quatre questions est oui, l’étape suivante d’approbation concerne généralement le workflow vidéo asynchrone et le modèle de coûts, et non la connectivité de base.

Si vous avez besoin de l’aspect tarifaire avant le déploiement, consultez ensuite la page de tarification en direct de Flatkey afin que l’équipe puisse approuver l’évaluation avec la même surface de facturation que celle utilisée en production.

FAQ

Quelle est la façon la plus rapide de tester l’accès à l’API Seedance via Flatkey ?

Commencez par le test de fumée actuel de Flatkey POST /v1/chat/completions pour vérifier l’authentification, l’URL de base et les Usage Logs. Une fois cela réussi, remplacez le modèle placeholder par l’ID de modèle Seedance actuellement approuvé et construisez le workflow vidéo asynchrone.

La première requête cURL génère-t-elle une vidéo ?

Non. La première requête cURL est une vérification de connectivité pour le routeur partagé. Elle prouve que votre clé, vos en-têtes, votre URL de base et les logs fonctionnent avant que vous n’ajoutiez la gestion des requêtes spécifique à la vidéo.

Avec quel modèle Seedance une équipe texte-vers-vidéo devrait-elle commencer ?

Au vendredi 17 juillet 2026, le catalogue public de modèles de Flatkey répertorie seedance-2.5 pour le texte-vers-vidéo et l’image-vers-vidéo. Vérifiez à nouveau le répertoire de modèles actuel avant de le figer dans le code produit.

Avec quel modèle Seedance une équipe image-vers-vidéo devrait-elle commencer ?

Au vendredi 17 juillet 2026, le catalogue public de Flatkey répertorie seedance-2.0-i2v pour l’image-vers-vidéo.

Pourquoi le flux d’onboarding commence-t-il par des complétions de chat plutôt que par une tâche vidéo ?

Parce que la requête chat-completions est la preuve la plus petite possible que votre chemin de routage compatible OpenAI fonctionne. Elle sépare les problèmes d’authentification et de journalisation des problèmes de pipeline vidéo.

Que dois-je inspecter dans la première réponse réussie ?

Inspectez model, choices[0].message.content et usage, puis confirmez que la même requête apparaît dans les Usage Logs.

Qu’est-ce qui change lorsque je passe du test de fumée à une évaluation Seedance réelle ?

La clé et l’URL de base restent les mêmes. L’ID du modèle, le corps de la requête et la gestion des tâches asynchrones changent.