Die Videoschnittstelle von Kling arbeitet mit asynchronen Aufgaben. Der erste Schritt der Einbindung ist deshalb nicht das Schreiben einer Anfrage, sondern das Beschaffen der Zugangsdaten, ihre richtige Ablage und die Begrenzung ihrer Rechte. Viele 401- und 403-Fehler sind keine Codeprobleme, sondern falsch kopierte Keys, nicht geladene Umgebungsvariablen oder Konten, für die das Modell gar nicht freigeschaltet ist.

Dieser Beitrag beschreibt in der Reihenfolge „Erstellen – Konfigurieren – Fehlersuche – Rotieren“ die üblichen Zugangsdatenformen und Sicherheitspraktiken der Kling-Plattform im Jahr 2026. Schnittstellendetails ändern sich schnell; maßgeblich sind die offizielle Konsole und Dokumentation.

Hinweis: Kling ist eine Marke der jeweiligen Rechteinhaber. Dieser Beitrag dient der technischen Erläuterung und begründet keine Zugehörigkeit oder Vertretungsbeziehung zu den genannten Unternehmen.

1. Zuerst klären, welche Zugangsdaten benötigt werden

Bei Kling sind derzeit zwei Authentifizierungsformen üblich:

  • API-Key: wird in der Entwicklerkonsole erstellt und bei Aufrufen im Header Authorization: Bearer <API_KEY> übergeben. Die neue Schnittstelle unterscheidet Modelle über den Pfad; diese Form ist zu bevorzugen.
  • AccessKey + SecretKey: wird vor allem für die alte Schnittstelle verwendet. Jede Anfrage signiert mit dem SecretKey ein JWT, das anschließend in den Bearer-Header kommt. Der AccessKey steht im iss-Claim.

Die Sicherheitsanforderungen unterscheiden sich: Ein API-Key ist ein langlebiger Zugang, der bei Offenlegung direkt genutzt werden kann. Beim AccessKey/SecretKey ist der SecretKey der Signaturschlüssel; nach Offenlegung kann ein Angreifer selbst Tokens ausstellen. Beides gehört weder in Frontend-Code noch in mobile Pakete oder öffentliche Repositories.

2. Schritte zum Erstellen eines Kling API Key

Der Konsoleneinstieg der internationalen Seite ist https://kling.ai/dev/api-key; nach Anmeldung mit dem Kling-Konto lassen sich Keys verwalten. Inländischer Einstieg und verfügbare Modelle richten sich nach der offiziellen Seite; Domains nicht aus Drittanbieter-Tutorials zusammensetzen.

  1. In der Entwicklerkonsole anmelden und die API-Key-Verwaltung öffnen.
  2. Auf „+ Create a new API Key“ klicken und nach „Projekt – Umgebung – Zweck“ benennen, etwa video-prod-cn oder video-test.
  3. Den Key sofort nach dem Erstellen kopieren und speichern. Die Seite zeigt ihn meist nur einmal; nach dem Schließen ist der vollständige Key nicht mehr sichtbar.
  4. Den Key in einen Passwortmanager oder einen Cloud-Secret-Dienst schreiben und Ersteller, Zweck und Rotationstermin dokumentieren.
  5. Die Authentifizierung mit einer Aufgabe zu minimalen Kosten prüfen und die zurückgegebene request_id für die spätere Fehlersuche notieren.
  6. Bestätigen, dass das Konto ein nutzbares Ressourcenpaket hat oder Postpaid freigeschaltet ist, dann mit der regulären Abstimmung beginnen.

Die Benennung ist keine Formalie. Bei auffälligen Aufrufen lässt sich anhand des Key-Namens schnell erkennen, welcher Dienst und welche Umgebung betroffen sind, statt alle Systeme gemeinsam abzuschalten.

3. Alte AccessKey/SecretKey-Authentifizierung mit JWT

Die alte Schnittstelle legt das Modell im Request-Body über model_name fest und verlangt ein selbst erzeugtes JWT. Laut offizieller Dokumentation gilt HS256, iss enthält den AccessKey, exp ist die aktuelle Zeit plus 1800 Sekunden, nbf die aktuelle Zeit minus 5 Sekunden.

import os
import time
import jwt  # PyJWT

access_key = os.environ["KLING_ACCESS_KEY"]
secret_key = os.environ["KLING_SECRET_KEY"]

token = jwt.encode(
    {
        "iss": access_key,
        "exp": int(time.time()) + 1800,
        "nbf": int(time.time()) - 5,
    },
    secret_key,
    algorithm="HS256",
    headers={"alg": "HS256", "typ": "JWT"},
)
print(token)

Einige leicht übersehene Punkte:

  • exp verwendet Unix-Sekunden, nicht Millisekunden. Millisekunden ergeben ein Token, das scheinbar lange gültig ist, aber von der Plattform abgelehnt werden kann.
  • Die Serverzeit muss synchron sein. Bei zu großer Abweichung schlägt die nbf-Prüfung fehl, sichtbar als „Token noch nicht gültig“.
  • Ein JWT ist nur 30 Minuten gültig. Beim Polling langer Aufgaben muss es neu erzeugt werden; ein Token reicht nicht bis zum Ende.
  • JWT und API-Key nicht vermischen. Die neue Schnittstelle nutzt den API-Key, nur die alte den AK/SK-Signaturweg; maßgeblich ist die jeweilige Schnittstellendokumentation.

4. Berechtigungen, Ressourcenpakete und Parallelitätslimits

Der zentrale Berechtigungsfehler in der Kling-Dokumentation ist Geschäftscode 1103 (HTTP 403): „keine Berechtigung für diese API oder dieses Modell“. Er hängt meist mit Kontostatus, Modellfreischaltung und Ressourcenpaket zusammen, nicht mit einem ungültigen Key.

Drei Limitarten sind zu unterscheiden:

  • Kontostatus: 1100 bedeutet anormalen Kontostatus; 1101 Rückstand bei Postpaid; 1102 aufgebrauchtes oder abgelaufenes Prepaid-Paket.
  • Modellberechtigung: 1103 bedeutet, dass das aktuelle Konto die Schnittstelle oder das Modell nicht aufrufen darf.
  • Parallelitätskontingent: Videoaufgaben erhalten je Ressourcenpaket Parallelitäts-Slots; bei Überschreitung kommt 1303. Laut Dokumentation teilen sich alle API-Keys eines Kontos denselben Parallelitätspool.

Das bedeutet: „Mehrere Keys anlegen“ bringt keine zusätzliche Parallelität und trennt Produktions- und Testverkehr nicht wirklich. Für harte Isolation sind separate Konten oder Pakete und eine Aufgabenwarteschlange in der Architektur nötig. Kling bietet in der Dokumentation derzeit keine feingranularen Scopes pro Schnittstelle (etwa nur Lesen oder nur Generieren); Rechte hängen an Konto und gebuchten Funktionen. Falls die Konsole später feinere Rechte einführt, gilt die Konsole.

5. Key in Umgebungsvariablen und Secret-Management ablegen

Mindestanforderung sind Umgebungsvariablen; in der Produktion sollte ein Secrets Manager des Cloud-Anbieters, ein Kubernetes Secret oder ein vergleichbarer Dienst verwendet werden. Den Key nicht in Git committen und nicht vollständig in Logs schreiben.

Empfohlene Variablennamen:

KLING_API_KEY=...
KLING_ACCESS_KEY=...
KLING_SECRET_KEY=...
KLING_BASE_URL=https://api-singapore.klingai.com

Im Repository nur eine .env.example mit Platzhaltern behalten. Beim Start prüfen, ob die Variablen vorhanden sind, und bei Fehlen sofort abbrechen, statt mit leeren Strings anzufragen. In Logs höchstens die ersten vier und letzten vier Zeichen des Keys plus die request_id erfassen. Browser und mobile Clients dürfen den Key nicht halten; alle Videoaufgaben laufen über einen Backend-Proxy.

6. Vergleichstabelle zur 401-Fehlersuche

Geschäftscode HTTP Bedeutung Häufige Ursache Behandlung
1000 401 Authentifizierung fehlgeschlagen Header-Format falsch Prüfen, ob Authorization vorhanden ist
1001 401 Auth-Header leer Umgebungsvariable leer, Proxy entfernt Header Länge der Variable ausgeben, Gateway-Weiterleitung prüfen
1002 401 Zugangsdaten ungültig Key unvollständig kopiert, widerrufen, falsche Umgebung Neu erstellen und Key aktualisieren
1003 401 Token noch nicht gültig Serverzeitabweichung, falsches nbf NTP synchronisieren, Zeiteinheit prüfen
1004 401 Token abgelaufen Altes JWT älter als 30 Minuten JWT neu erzeugen

Die Reihenfolge der Prüfung von außen nach innen: zuerst bestätigen, dass der Header tatsächlich mitgesendet wird, dann, dass der Key zur aktuellen Umgebung gehört, und erst zuletzt die Plattformseite verdächtigen. Bei Reverse Proxys oder Serverless-Plattformen prüfen, ob sie den Authorization-Header filtern.

7. Offizielle Direktverbindung oder API-Gateway

Bei direkter Verbindung zur Kling-Plattform liegen Konto, Ressourcenpaket, Aufruflogs und Rechnung beim eigenen Team; das passt zu Teams mit Beschaffungs- und Betriebserfahrung. Über ein API-Gateway lassen sich mehrere Videoanbieter unter einem Key und einer Rechnung bündeln, was den Integrationsaufwand senkt.

Bei der Gateway-Wahl vier Punkte klären: Ist der Kling-Videokanal freigeschaltet, werden asynchrone Aufgaben und external_task_id unverändert unterstützt, lässt sich die Callback-Adresse durchreichen, und wie werden Ergebnis-URLs ausgeliefert? Ein Gateway, das nur OpenAI-kompatible Textschnittstellen anbietet, ist für Videoaufgaben nicht direkt geeignet. Die Modelle und Preise ansehen und bei Bedarf einen Testzugang registrieren; zuerst mit einer minimalen Aufgabe validieren, dann über die Migration des Produktionsverkehrs entscheiden.

8. Rotation und Umgang mit Offenlegung

Key-Rotation sollte Routine sein, nicht erst im Notfall erfolgen. Empfohlen alle 90 Tage sowie sofort bei Personalwechsel oder Projektübergabe.

  1. In der Konsole einen neuen Key mit Datum im Namen anlegen, etwa video-prod-20261019.
  2. Den neuen Key im Secret-Management hinterlegen, die Testumgebung aktualisieren und eine kürzeste Aufgabe durchlaufen.
  3. Die Produktion schrittweise umstellen und 401, 403 sowie Erfolgsrate beobachten.
  4. Nach Stabilisierung des neuen Keys den alten widerrufen.
  5. Rotationszeitpunkt, Ausführenden und betroffene Dienste dokumentieren.

Bei Verdacht auf Offenlegung zuerst den alten Key widerrufen, dann Aufruflogs und Rechnung prüfen und erst danach den Offenlegungsweg untersuchen. Nur den Code zu ändern, ohne den Key zu widerrufen, lässt das Risiko bestehen. Das Webhook Secret ist ein separates Credential; offiziell können alter und neuer Secret sieben Tage parallel bestehen und getrennt vom API-Key rotiert werden.

Häufige Fragen

Worin unterscheiden sich Kling API Key und AccessKey/SecretKey?

Der API-Key ist ein einzelner Zugang, der direkt im Bearer-Header steht; AccessKey/SecretKey ist der ältere Signaturmechanismus, bei dem ein JWT selbst erzeugt wird. Neue Schnittstellen bevorzugen den API-Key, alte folgen der Dokumentation mit JWT.

Kann ein Konto mehrere API-Keys erstellen, und addiert sich die Parallelität?

Keys lassen sich nach Umgebung und Projekt anlegen, aber laut Dokumentation teilen alle Keys eines Kontos denselben Parallelitätspool; weitere Keys erhöhen die Parallelität nicht. Für harte Isolation separate Konten oder Pakete verwenden.

401 meldet ungültige Zugangsdaten, aber der Key sieht richtig aus?

Prüfen, ob die Zeichenkette vollständig kopiert wurde, ob Leerzeichen oder Zeilenumbrüche enthalten sind, ob die Anfrage an die richtige Region geht und ob ein Proxy den Authorization-Header verändert oder entfernt. Bleibt es unklar, einen neuen Key als Vergleichstest anlegen.

Läuft ein Kling API Key ab?

Der API-Key selbst läuft üblicherweise nicht nach einer festen Frist ab, kann aber durch Widerruf, Kontostatus oder Rechteänderungen ungültig werden. Ein altes JWT ist 30 Minuten gültig. Maßgeblich sind Konsole und offizielle Dokumentation.

Braucht man mit einem API-Gateway noch ein eigenes Kling-Konto?

Nicht zwingend. Ein Gateway verwaltet meist Upstream-Konto und Abrechnung, aber verfügbare Modelle, Parallelität, Callback-Fähigkeit und Datenaufbewahrung bestimmt das Gateway. Vor der Einbindung klären, ob der Videokanal freigeschaltet ist, und die Servicethemen lesen.

Weiterlesen: