Kimi API Key erstellen: Registrierung und Sicherheit (2026)

Ein Kimi API Key ist der Zugangsnachweis für die Open Platform – weder eine Mitgliedschaft der Webversion noch ein Guthaben. Viele Teams hängen beim ersten Anschluss nicht am Modellwissen fest, sondern an der falschen Seite, einem falsch gespeicherten Key oder der Verwechslung von Mitgliedskonto und API-Konto.

Dieser Artikel folgt der praktischen Reihenfolge: zuerst die Kontosysteme trennen, dann Registrierung, Verifizierung und Key-Erstellung, anschließend Speicherung, Rotation und 401-Diagnose, zuletzt der Vergleich zwischen offiziellem Key und Gateway-Key. Modelle und Preise richten sich nach unseren Modellpreisen.

Hinweis: Moonshot und Kimi sind Marken ihrer jeweiligen Inhaber; der Artikel dient der technischen Anbindung. Zugang, Verifizierungsanforderungen und Key-Verwaltungsregeln können sich ändern; maßgeblich sind die aktuellen Seiten der offiziellen Konsole.

1. Zuerst drei Arten von „Kimi-Konto“ unterscheiden

Typ	Zugang	Zweck	Guthaben und Key
Kimi Web und App-Mitgliedschaft	kimi.com	Chat-Produkt	Unabhängig von der API
Kimi Open Platform (China)	platform.kimi.com	Inländische API-Aufrufe	Eigenes Konto, Guthaben und Keys
Kimi Open Platform (international)	platform.kimi.ai	Ausländische API-Aufrufe	Vollständig getrennt von der China-Seite

Keys der China- und der internationalen Seite sind nicht austauschbar. Ein Key der China-Seite an der internationalen Adresse – oder umgekehrt – führt häufig zu 401. Es gibt einen dritten Weg: einen Gateway-Key im ZSQH AI Gateway erstellen und damit mehrere Modelle inklusive Kimi aufrufen; Key und Guthaben werden vom Gateway verwaltet.

Zuerst festlegen, welche Seite das Geschäft nutzt, dann registrieren. Nicht mit einem Mitgliedskonto nach Keys suchen und parallel auf der Open Platform aufladen – das sind zwei verschiedene Produkte.

2. Registrierung und Identitätsverifizierung

platform.kimi.com öffnen und der Anleitung zur Registrierung und Anmeldung folgen.
Ins Nutzerzentrum gehen und die persönliche Identitätsprüfung abschließen; für Firmenaufrufe die Unternehmensverifizierung.
Für die Unternehmensverifizierung üblicherweise Firmenname, ein zum Rechtsträger passendes Bankkonto und den einheitlichen Sozialkreditcode bereithalten.
Die Plattform überweist einen Zufallsbetrag auf das Firmenkonto; nach Bestätigung durch die Finanzabteilung den Betrag eintragen, bei Übereinstimmung ist die Prüfung bestanden.
Erst nach der Verifizierung aufladen. Privatnutzer können online aufladen, Unternehmen zusätzlich per Firmenüberweisung.
In der Konsole Kontostatus, Guthaben und verfügbare Modelle prüfen.

Der verifizierte Rechtsträger lässt sich nur von privat zu Unternehmen ändern, nicht zurück. Schon bei der Registrierung klären, welcher Rechtsträger genutzt wird. Rechnungen, Verträge und Beschaffung sind meist an diesen Rechtsträger gebunden; eine spätere Änderung ist aufwendig.

3. Schritte zum Erstellen eines API Key

Nach der Anmeldung https://platform.kimi.com/console/api-keys öffnen.
Auf API Key erstellen klicken und nach „Projekt-Umgebung-Zweck“ benennen, etwa crm-prod-chat.
Den erzeugten Key kopieren. Wird er nur einmal angezeigt, sofort in einen Secret Manager legen und nicht im Chatverlauf lassen.
In der Testumgebung eine Minimalanfrage senden und Key, Seite und Modellname gemeinsam bestätigen.
Erstellungszeit, Verantwortlichen, Projektbindung und geplantes Rotationsdatum dokumentieren.
Produktion, Test und persönliche Entwicklung mit getrennten Keys betreiben; nicht mehrere Personen mit einem Key.

Rechteumfang und ob eine Unterteilung nach Projekt oder Mitglied möglich ist, richten sich nach den tatsächlichen Optionen der Konsole. Nicht annehmen, dass nicht angebotene Rechte existieren; für Isolation mehrere Konten oder Keys plus Anwendungskontingente nutzen.

4. Rotation, Widerruf und Rechtebegrenzung

Behandeln Sie Keys als Zugangsdaten mit Lebenszyklus, nicht als einmal erstellt und dauerhaft gültig.

Regelmäßige Rotation: normale Projekte alle 90 Tage, Kerngeschäft kürzer.
Sofort bei Personalwechsel: Bei Austritt, Wechsel oder Ende eines Outsourcings zuerst widerrufen, dann neu ausgeben.
Sofort bei Leckage: Nicht erst den Verbrauch beobachten, sondern zuerst sperren.
Überlappende Ausgabe: Neuen Key erstellen, deployen und prüfen, dann den alten widerrufen, um Ausfälle beim Wechsel zu vermeiden.
Minimale Rechte: Ein Key dient einem Projekt oder einer Umgebung, damit der Auswirkungsbereich kontrollierbar bleibt.
Nachvollziehbarkeit: Logs nur mit Key-Präfix und Name, nie mit dem vollständigen Wert.

Rotation ist keine Formsache. Viele Vorfälle mit „plötzlich aufgebrauchtem Kontingent“ gehen auf alte Keys in Skripten, Repositories oder Chatverläufen zurück.

5. Sichere Speicherung: Umgebungsvariablen sind nur der Anfang

Die minimale Anforderung: Keys nicht in den Code schreiben. Lokal .env nutzen und sicherstellen, dass die Datei von Git ignoriert wird; in der Produktion einen Secret Manager oder injizierte Umgebungsvariablen verwenden.

# .env nur lokal, nicht ins Repository einchecken
MOONSHOT_API_KEY=IHR-SCHLUESSEL

# .gitignore mindestens
.env
.env.*

Darüber hinaus drei Maßnahmen:

In Frontend, Mobile und Browser-Erweiterungen darf kein Key erscheinen; alle Aufrufe laufen über den Server.
In Logs, Fehlerberichten und APM den Authorization-Header filtern, damit der Key nicht vollständig protokolliert wird.
In CI/CD ein separates Secret-Management nutzen und nichts im Build-Skript im Klartext ausgeben.

Wenn mehrere Personen eine Entwicklungsmaschine teilen, reichen Umgebungsvariablen nicht zur Isolation. Besser ist ein Entwicklungs-Key pro Person mit personenbezogener Verbrauchsaufzeichnung, damit Probleme zuordenbar sind.

6. 401-Diagnosereihenfolge

401 bedeutet nicht zwingend, dass der Key falsch ist. Die folgende Reihenfolge führt meist in wenigen Minuten zur Ursache.

Symptom	Häufige Ursache	Behandlung
`invalid_authentication_error`	Key-Format falsch, gelöscht, unvollständig kopiert	Neu erstellen und vollständig kopieren
`incorrect_api_key_error`	Key fehlt, Header falsch geschrieben	`Authorization: Bearer` prüfen
401 direkt nach Umgebungswechsel	China- und internationale Keys vermischt	Seite und Base URL vereinheitlichen
403 `permission_denied_error`	IP-Whitelist, Schnittstelle nicht freigeschaltet	Konsolenrechte und Netzausgang prüfen
404	Base URL oder Modellname falsch	Modellliste und Pfad prüfen

Einzeln prüfen:

Zu welcher Seite gehört der Key, passt die Base URL?
Enthält der Key Leerzeichen, Zeilenumbrüche oder Anführungszeichen?
Wird die Umgebungsvariable tatsächlich geladen? Die ersten Zeichen ausgeben.
Wurde der Key gelöscht, deaktiviert oder bereits rotiert?
Lautet der Header Authorization: Bearer <key>?
Ist der Pfad /v1/chat/completions, und fehlt oder doppelt sich /v1?
Mit einem neuen Key gegentesten, um Key- und Gateway-Konfigurationsprobleme zu trennen.

7. Offizieller Key oder Gateway-Key?

Vergleichspunkt	Offizielle Direktverbindung	ZSQH AI Gateway
Erstellung	Konsole der Kimi Open Platform	Gateway-Konsole
Kontosystem	China- oder internationale Seite	Gateway-Konto
Abrechnung	Plattform-Aufladung, Rechnung nach Plattformregeln	RMB-Aufladung, Rechnung nach Gateway-Regeln
Modellumfang	Kimi-Serie	Einheitlicher Zugang für mehrere Modelle
Geeignet für	Nur Kimi, offizielle Direktfunktionen nötig	Modellwechsel, einheitliche Rechnung und Keys

Nur Kimi, Team in China, stabiler offizieller Zugang: Die Direktverbindung ist am einfachsten. Wer zusätzlich DeepSeek, GLM oder Claude nutzt oder einen Key für mehrere Modelle und eine einheitliche RMB-Rechnung wünscht, ist mit dem Gateway besser bedient. Die Wege schließen sich nicht aus – zuerst mit dem Gateway testen, dann über die Produktionsroute entscheiden.

8. Checkliste für Teams

Nutzungsrechtsträger klären und passende Verifizierung abschließen.
Eine Seite, ein Konto; China- und internationale Seite nicht mischen.
Ein Projekt, ein Key; eine Umgebung, ein Key.
Keys nur im Secret Manager, nicht im Repository.
Rotationszyklus und Verantwortliche festlegen.
Guthabenwarnung aktivieren, damit Rückstände nicht zu abgelehnten Aufrufen oder 429 führen.
Im Monitoring 401, 403 und 429 unterscheiden, nicht alles als „Key ungültig“ behandeln.

Häufige Fragen

Was tun, wenn ein Key offengelegt wurde?

Den Key sofort in der Konsole widerrufen oder löschen, einen neuen Key erstellen und deployen, dann Verbrauch und Rechnung prüfen. Nicht nur die Zeichenkette im Code ändern – ein alter Key bleibt ohne Widerruf gültig.

Kann ein Key für mehrere Projekte genutzt werden?

Technisch meist ja, empfehlenswert ist es nicht. Gemeinsame Nutzung macht Verbrauch, Rate-Limits und Störungen nicht zuordenbar. Keys je Projekt plus Anwendungskontingente senken den Diagnoseaufwand.

Läuft ein Kimi API Key ab?

Ob eine Gültigkeitsdauer gesetzt wird, richtet sich nach den aktuellen Konsolenregeln. Auch ohne erzwungenes Ablaufdatum ist eine aktive Rotation sinnvoll, besonders bei Personalwechsel oder lange ungenutzten Keys.

Warum 401 trotz aufgeladenem Guthaben?

Zuerst prüfen, ob Aufladung und Key zur selben Seite und zum selben Rechtsträger gehören. Dann mit einem neu erstellten Key testen, um gelöschte Keys, nicht aktualisierte Umgebungsvariablen oder fest eingetragene Altwerte im Code auszuschließen.

Lassen sich offizieller Key und Gateway-Key mischen?

Nein. Base URL, Authentifizierungssystem und Guthabenkonto unterscheiden sich. Typische Folgen sind 401 oder 404; beim Wechsel müssen Key, Base URL und Modellname gemeinsam geändert werden.

Nächste Schritte

Erstellen Sie zunächst einen Test-Key im ZSQH AI Gateway, prüfen Sie die Kette mit einer Minimalanfrage und teilen Sie dann Produktions-Keys nach Projekt auf. Verfügbare Modelle und Abrechnung richten sich nach den Modellpreisen.

Verwandte Artikel: