Comment utiliser l'API Kling sans onboarding direct chez Kling : guide 2026

TL;DR Vous pouvez accéder aux modèles vidéo Kling pris en charge via CometAPI avec un compte CometAPI et une clé API, sans passer par un processus d’onboarding développeur Kling distinct. L’itinéraire actuel pour texte vers vidéo est POST /kling/v1/videos/text2video. Il renvoie un ID de tâche que votre backend sonde jusqu’à ce que la tâche atteigne succeed ou failed. La disponibilité des modèles, les paramètres, la tarification et l’éligibilité des comptes peuvent évoluer ; vérifiez donc le catalogue de modèles en ligne et la documentation API avant un déploiement en production.

Réponse directe

La voie pratique est le Catalogue des modèles Kling de CometAPI. Si le modèle Kling dont vous avez besoin est disponible pour votre compte CometAPI, votre serveur peut s’authentifier avec une clé API CometAPI et appeler le point de terminaison compatible Kling correspondant. Avec cette voie, une demande d’API Kling séparée ne fait pas partie des étapes d’intégration.

Cette distinction est importante pour les équipes qui utilisent déjà CometAPI pour d’autres modèles. L’application conserve une seule surface de gestion des identifiants et une seule relation fournisseur tout en ajoutant un workflow vidéo Kling. Votre code doit néanmoins utiliser le schéma de requête spécifique à la vidéo de Kling et son cycle de vie asynchrone des tâches ; « une seule clé API » ne signifie pas que tous les fournisseurs partagent un corps de requête identique.

Cet article se concentre sur le texte vers vidéo car c’est l’intégration utile la plus minimale. CometAPI documente également l’image vers vidéo et d’autres workflows Kling, chacun avec son propre point de terminaison et ses contraintes de paramètres. Commencez par un chemin vérifié, puis ajoutez des capacités uniquement après avoir consulté la documentation à jour.

Pourquoi cette voie peut être utile pour une équipe de développement

Le bénéfice immédiat est opérationnel plutôt que magique. Une équipe qui utilise déjà CometAPI peut ajouter un workflow Kling disponible sans créer une autre intégration directe fournisseur, distribuer un autre identifiant ni construire un parcours de gestion de compte séparé. Cela peut réduire le nombre de secrets, de relations de facturation et de configurations client spécifiques au fournisseur que votre plateforme doit maintenir.

Le second bénéfice est architectural. Votre application peut exposer un petit contrat interne de génération vidéo — prompt, workflow, modèle, options et statut de job — tandis qu’un adaptateur fournisseur traduit ce contrat en requête Kling documentée. Si l’équipe évalue ultérieurement un autre modèle vidéo, le modèle de job orienté produit peut rester stable même si les chemins, paramètres et métadonnées de sortie diffèrent.

La limitation est tout aussi importante : une couche d’accès consolidée ne rend pas les modèles sous-jacents interchangeables. Le comportement des prompts, les médias acceptés, la latence, la tarification, les politiques de sécurité et les schémas de résultat peuvent varier. Gardez ces différences visibles dans la configuration et les tests, au lieu de les masquer derrière des hypothèses non prises en charge.

Ce que cette voie d’accès change — et ce qu’elle ne change pas

Ce qui change. Vous créez et gérez une clé CometAPI, envoyez des requêtes vers l’API compatible Kling de CometAPI et suivez l’usage côté CometAPI. Cela supprime une étape distincte d’onboarding direct Kling pour cette voie d’accès particulière.

Ce qui ne change pas. Kling reste la famille de modèles sous-jacente. Les paramètres spécifiques au fournisseur, le comportement de génération, les règles d’utilisation acceptable, la disponibilité des modèles et les caractéristiques de sortie restent déterminants. La documentation de CometAPI note également que les champs de requête et de réponse peuvent différer selon le fournisseur ; considérez donc la référence de l’endpoint en ligne comme le contrat de votre implémentation.

Ce que vous devez vérifier avant de vous engager. Confirmez que votre compte peut accéder à l’ID de modèle requis, passez en revue le prix et les limites de débit actuels, et exécutez un petit test authentifié. Ne concevez pas un workflow de production autour d’un nom de modèle trouvé dans un ancien article de blog ou un exemple mis en cache.

Avant de commencer

Vous avez besoin d’un compte CometAPI, d’une clé API stockée sur votre serveur et d’un backend capable d’exécuter une tâche asynchrone. Conservez la clé dans une variable d’environnement telle que COMETAPI_KEY ; ne l’exposez pas dans du code navigateur ou mobile.

1. Ouvrez le catalogue des modèles Kling et confirmez que le modèle que vous souhaitez utiliser est actuellement listé pour votre compte.
2. Consultez la référence API actuelle texte vers vidéo de Kling. Au moment de la vérification, l’exemple documenté utilise kling-v3.
3. Créez une clé API côté serveur dans la console CometAPI et définissez-la dans votre environnement d’exécution.
4. Décidez où votre service stockera l’ID de tâche et la vidéo finale. La requête de génération renvoie une tâche, pas le fichier vidéo terminé.

Choisir le workflow Kling avant de concevoir la requête

Partez de l’actif dont dispose déjà votre produit. Si l’utilisateur n’a qu’un concept écrit, le texte vers vidéo est le chemin direct. Si l’utilisateur a une image fixe qui doit rester l’ancre visuelle, utilisez la voie image vers vidéo documentée séparément. N’ajoutez pas un champ image à une requête texte vers vidéo en supposant que l’API déduira le workflow.

La référence actuelle image vers vidéo accepte une URL d’image publique ou une chaîne d’image base64 et renvoie une tâche asynchrone. Les workflows Kling plus spécialisés ont leurs propres pages et contraintes de requête. Ajoutez-les un par un uniquement lorsque le besoin produit et la documentation à jour justifient l’adaptateur supplémentaire.

Pour une première validation en production, utilisez un seul workflow, un seul ID de modèle vérifié, une durée courte et un petit ensemble de prompts représentatifs. Cela isole l’accès au compte et l’orchestration des tâches de l’évaluation subjective des sorties. Une fois le pipeline fiable, comparez les modes ou les modèles avec un jeu d’évaluation fixe plutôt que de changer plusieurs variables dans le même test.

Effectuer votre première requête Kling texte vers vidéo

Le point de terminaison texte vers vidéo actuel accepte du JSON et l’authentification Bearer. Commencez avec un prompt court et la durée la plus petite prise en charge. La requête suivante n’utilise que les champs figurant dans la référence CometAPI actuelle :

curl https://api.cometapi.com/kling/v1/videos/text2video \
  -H "Authorization: Bearer $COMETAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "A small ceramic cup on a wooden table, steam rising in soft morning light",
    "model_name": "kling-v3",
    "mode": "std",
    "duration": "5",
    "sound": "off"
  }'

Une soumission réussie renvoie un objet contenant data.task_id et un statut de tâche. Enregistrez cet ID de tâche avec le job de votre application. Ne maintenez pas la connexion HTTP ouverte pendant le rendu de la vidéo.

Gérer la tâche asynchrone en toute sécurité

La génération Kling est asynchrone. Pour texte vers vidéo, sondez GET /kling/v1/videos/text2video/{task_id}. La référence des tâches CometAPI indique qu’une réponse peut renvoyer la tâche directement ou à l’intérieur d’une enveloppe data, donc l’exemple normalise ces deux formes. Il traite également tout état non terminal comme « attendre », au lieu de supposer une liste fixe d’états intermédiaires.

import os
import time
import requests

API_KEY = os.environ["COMETAPI_KEY"]
BASE_URL = "https://api.cometapi.com/kling/v1/videos/text2video"
HEADERS = {
    "Authorization": f"Bearer {API_KEY}",
    "Content-Type": "application/json",
}


def submit_video(prompt: str) -> str:
    response = requests.post(
        BASE_URL,
        headers=HEADERS,
        json={
            "prompt": prompt,
            "model_name": "kling-v3",
            "mode": "std",
            "duration": "5",
            "sound": "off",
        },
        timeout=30,
    )
    response.raise_for_status()
    payload = response.json()
    return payload["data"]["task_id"]


def wait_for_video(task_id: str, timeout_seconds: int = 600) -> str:
    deadline = time.monotonic() + timeout_seconds
    poll_url = f"{BASE_URL}/{task_id}"

    while time.monotonic() < deadline:
        response = requests.get(poll_url, headers=HEADERS, timeout=30)
        response.raise_for_status()
        payload = response.json()
        task = payload.get("data") or payload
        status = task.get("task_status")

        if status == "succeed":
            videos = task.get("task_result", {}).get("videos", [])
            if not videos or not videos[0].get("url"):
                raise RuntimeError("Task succeeded without a video URL")
            return videos[0]["url"]

        if status == "failed":
            detail = task.get("task_status_msg") or task.get("task_result")
            raise RuntimeError(f"Kling task failed: {detail}")

        time.sleep(10)

    raise TimeoutError(f"Kling task {task_id} exceeded {timeout_seconds}s")


task_id = submit_video(
    "A small ceramic cup on a wooden table, steam rising in soft morning light"
)
video_url = wait_for_video(task_id)
print(video_url)

La chaîne de succès terminal est succeed, et non succeeded. Quand une tâche se termine, copiez la ressource générée dans un stockage que vous contrôlez si votre produit requiert une rétention. Les URL de livraison du fournisseur ne doivent pas être considérées comme un stockage permanent pour l’application.

Pour des charges plus importantes, utilisez une file ou un worker plutôt que d’interroger au sein d’une requête web. CometAPI documente également des URL de callback pour les tâches Kling. Si vous adoptez des webhooks, authentifiez et dédupliquez les événements de callback, et conservez un recours au sondage pour les livraisons manquées.

Concevoir le cycle de vie des jobs applicatifs avant de passer à l’échelle

Considérez la tâche fournisseur comme une partie de votre propre enregistrement de job. Stockez un ID de job applicatif, le workflow, le modèle demandé, l’ID de tâche fournisseur, l’URL de requête, le statut courant, l’horodatage de soumission, la dernière interrogation et l’emplacement de sortie. Cela donne à vos équipes support et opérations suffisamment de contexte pour enquêter sur une génération échouée ou lente sans fouiller les journaux de requêtes brutes.

Ne renvoyez pas la requête de création simplement parce que le client n’a pas reçu de réponse. Le fournisseur a peut-être déjà créé une tâche. Persistiez votre job local avant la soumission, enregistrez immédiatement l’ID de tâche renvoyé et séparez les retries de création de ceux de consultation de statut. La référence texte vers vidéo actuelle documente également external_task_id pour le suivi ; confirmez son comportement réel avant d’en faire un mécanisme de déduplication.

const TERMINAL = new Set(["succeed", "failed"]);

function normalizeKlingTask(payload) {
  const task = payload?.data ?? payload;
  if (!task?.task_id || !task?.task_status) {
    throw new Error("Kling response is missing task identity or status");
  }
  return task;
}

async function refreshVideoJob(job, apiKey) {
  const response = await fetch(job.queryUrl, {
    headers: { Authorization: `Bearer ${apiKey}` },
  });

  if (!response.ok) {
    throw new Error(`Task query failed with HTTP ${response.status}`);
  }

  const task = normalizeKlingTask(await response.json());
  const outputUrl = task.task_result?.videos?.[0]?.url ?? null;

  return {
    ...job,
    providerTaskId: task.task_id,
    providerStatus: task.task_status,
    terminal: TERMINAL.has(task.task_status),
    outputUrl,
    failureDetail: task.task_status_msg ?? null,
    checkedAt: new Date().toISOString(),
  };
}

Cet exemple ne traduit délibérément pas chaque état intermédiaire possible du fournisseur en promesse produit. Votre worker garde les tâches non terminales actives, gère explicitement succeed et failed, et enregistre le statut brut du fournisseur pour le débogage. Ajoutez un délai d’expiration applicatif séparé afin qu’une tâche bloquée ne reste pas ouverte indéfiniment.

Utilisez le sondage comme base, car l’ID de tâche reste interrogeable. Lorsque l’endpoint sélectionné prend en charge callback_url, un webhook peut réduire les requêtes répétées de statut, mais il ne doit pas devenir votre seul mécanisme de reprise. Le guide officiel sur le sondage et les webhooks note que les charges de callback peuvent être spécifiques au fournisseur. Stockez l’événement brut, rendez le traitement idempotent par ID de tâche, renvoyez rapidement une réponse HTTP réussie et conciliez l’état terminal via le sondage.

Liste de contrôle de production pour les équipes de développement

• Valider le modèle à l’exécution. Vérifiez le catalogue actuel et échouez clairement lorsqu’un modèle demandé est indisponible. Ne substituez pas silencieusement un autre modèle si le comportement de sortie est important.
• Séparer soumission et récupération. Stockez l’ID de tâche CometAPI, votre propre ID de job, le modèle sélectionné et les horodatages afin que les retries ne créent pas de travail en double.
• Borner le sondage. Utilisez un délai d’expiration, un backoff exponentiel ou un intervalle raisonnable fixe, et un nombre maximal de tentatives. Consultez les conseils sur limites de débit et concurrence de CometAPI avant d’augmenter le parallélisme.
• Classifier les erreurs. Ne réessayez pas en cas de paramètres invalides ou d’échec d’authentification. Appliquez du backoff aux erreurs de plateforme et de limite de débit réessayables, conformément au guide actuel sur les codes d’erreur et la stratégie de retry.
• Protéger les identifiants et les entrées. Gardez les clés API côté serveur, évitez de journaliser des secrets et confirmez que les utilisateurs ont les droits sur les prompts, images ou autres sources soumises.
• Mesurer le job de bout en bout. Suivez la réussite de soumission, le temps en file, le temps de génération, le taux d’échec terminal, le taux de timeout, la réussite de récupération de la sortie et le coût par modèle et mode.
• Persister les sorties de manière délibérée. Téléchargez les ressources terminées vers un stockage que vous contrôlez lorsque votre produit requiert un accès durable, puis appliquez votre politique de rétention et de suppression.

FAQ pratiques

Ai-je besoin d’un compte développeur Kling séparé pour cette voie ?

Aucune étape d’onboarding développeur Kling séparée n’apparaît dans le flux d’intégration CometAPI. Vous utilisez un compte et une clé API CometAPI. L’accès dépend toutefois du modèle disponible pour votre compte CometAPI et votre région, donc confirmez cela avant de vous engager en production.

L’API Kling est-elle entièrement compatible OpenAI ?

Pas pour le workflow vidéo présenté ici. Il utilise des routes spécifiques à Kling telles que /kling/v1/videos/text2video et des champs spécifiques à Kling. Vous pouvez gérer l’identifiant via CometAPI, mais votre adaptateur doit préserver le schéma propre au fournisseur.

Quel ID de modèle Kling dois-je utiliser ?

La référence texte vers vidéo actuelle de CometAPI utilise kling-v3 dans son premier exemple fonctionnel et liste plusieurs pistes antérieures. Utilisez un ID de modèle provenant de l’énumération de l’endpoint en ligne et vérifiez qu’il est activé pour votre compte. N’assumez pas que le modèle le plus récent est disponible partout.

Pourquoi la première réponse ne contient-elle pas une vidéo ?

La génération vidéo s’exécute comme une tâche asynchrone. La réponse initiale renvoie un ID de tâche. Sondez la route de requête correspondante jusqu’à ce que task_status devienne succeed ou failed, puis lisez les métadonnées de résultat.

Dois-je sonder ou utiliser une URL de callback ?

Le sondage est plus simple pour une première intégration. Les callbacks réduisent les requêtes répétées à l’échelle mais exigent un récepteur authentifié, idempotent et une logique de reprise. De nombreux systèmes de production utilisent les callbacks comme voie principale et le sondage comme secours.

Puis-je utiliser l’image vers vidéo via le même endpoint ?

Non. CometAPI documente l’image vers vidéo sous une route distincte, /kling/v1/videos/image2video. Suivez le schéma de requête actuel de cet endpoint au lieu d’ajouter un champ image à l’exemple texte vers vidéo.

Dois-je commencer avec le mode standard ou professionnel ?

Utilisez std pour valider l’authentification, la forme de requête, le stockage de la tâche, le sondage et la récupération de sortie. La référence actuelle décrit pro comme un mode de meilleure qualité et plus coûteux. Évaluez-le avec des prompts représentatifs seulement après que le workflow de base fonctionne, et comparez la qualité de sortie avec le temps de génération et le coût réel.

Comment éviter les générations en double lors des retries ?

Créez un enregistrement de job applicatif avant d’appeler l’API et enregistrez immédiatement l’ID de tâche fournisseur renvoyé. Réessayez les requêtes de statut indépendamment des requêtes de création. Ne supposez pas que répéter le même POST est idempotent. L’endpoint documente actuellement external_task_id pour le suivi, mais vérifiez sa sémantique actuelle avant d’en faire une garantie de déduplication.

Conclusion

Pour une équipe de développement américaine souhaitant tester la génération vidéo Kling sans compléter une demande développeur directe Kling, CometAPI fournit une voie documentée : vérifiez que le modèle Kling requis est disponible pour le compte, authentifiez-vous avec une clé CometAPI, appelez l’endpoint spécifique au workflow et suivez la tâche asynchrone jusqu’à un état terminal.

La valeur d’ingénierie pratique est un accès centralisé et un modèle de tâche applicative réutilisable — pas l’hypothèse que tous les fournisseurs vidéo se comportent de la même manière. Conservez un adaptateur fin pour chaque workflow, conservez l’identité des tâches et les sorties de manière délibérée, et gardez le sondage comme chemin de reprise même lorsque les callbacks sont activés.

Un déploiement sûr est petit et mesurable : validez un modèle et un workflow, soumettez des jobs courts et peu coûteux, enregistrez les taux de réussite et d’échec terminaux, vérifiez la récupération de la sortie et comparez le coût et la latence réels aux exigences de votre produit. Étendez-vous à l’image vers vidéo ou à d’autres workflows Kling uniquement après avoir vérifié la documentation actuelle et votre compte cible.