Viele Entwickler suchen nach „Moonshot API Key“, öffnen platform.moonshot.cn und landen auf einer anderen Domain – und zweifeln, ob sie die falsche Seite erwischt haben. Tatsächlich wurde die Marke angepasst: Moonshot ist die Marke von Unternehmen und offener Plattform, Kimi die Modellmarke, und die API-Anfragedomain behält weiterhin moonshot. Dieser Artikel beschreibt den tatsächlichen Zugang im Jahr 2026 sowie Kontostufen, Key-Rechte, Speicherung, Rotation und die 401-Fehleranalyse.

Hinweis: Moonshot und Kimi sind Marken ihrer jeweiligen Inhaber; dieser Artikel dient ausschließlich der technischen Anbindung. Plattformzugang, Verifizierungsanforderungen und Key-Verwaltungsregeln können sich ändern; maßgeblich ist die aktuelle Seite in der Konsole.

1. Wo der Zugang zur Moonshot-Plattform heute liegt

platform.moonshot.cn leitet derzeit auf platform.kimi.com weiter, die internationale Seite platform.moonshot.ai auf platform.kimi.ai. Konsole, Konto, Guthaben und Keys werden auf der Kimi-API-Plattform verwaltet.

Die API-Anfragedomain bleibt jedoch unverändert: China api.moonshot.cn, international api.moonshot.ai. Manche alten Anleitungen haben nur die Konsolenscreenshots ersetzt, ohne das zu erklären – daher der Eindruck, die Plattform sei verschwunden.

Merken Sie sich drei Ebenen: Moonshot ist die Plattformmarke, Kimi die Modellmarke, api.moonshot.* die Schnittstellendomain. Das sind keine drei Kontosysteme. Konten, Guthaben und Keys von China- und internationaler Seite sind voneinander getrennt; Key und Seite müssen zusammenpassen.

2. Zuerst den Rechtsträger wählen: unverifiziert, privat oder Unternehmen

Verifizierungsstatus Maximale Projekte Maximale API Keys Geeignet für
Unverifiziert 1 10 Kurzfristige Tests
Persönlich verifiziert 20 50 Persönliche Entwicklung, kleine Teams
Firmenverifiziert 50 100 Mehrere Projekte und Mitglieder

Die Zahlen stammen aus der aktuellen Dokumentation; die Konsole kann sie anpassen. Nach der Firmenverifizierung lassen sich Mitglieder einladen, Rechte pro Projekt vergeben und Rechnungen ausstellen; persönlich verifizierte Konten können keine Mitglieder einladen. Regeln zum Wechsel des Rechtsträgers richten sich nach der Konsole. Vor der Registrierung entscheiden, ob ein privater oder Firmenrechtsträger verwendet wird; ein späterer Wechsel betrifft oft Vertrag und Rechnung.

Auf Organisationsebene gibt es zudem eine IP-Whitelist, verfügbar für persönlich und firmenverifizierte Organisationen. Sie gilt für die gesamte Organisation und beschränkt alle Keys gemeinsam; maximal 20 öffentliche IPv4-Adressen oder CIDR-Bereiche, keine IPv6- und keine privaten Adressen. Jedes Speichern überschreibt die gesamte Liste; bei wechselnder Ausgangs-IP nicht unbedacht aktivieren.

3. Die richtige Reihenfolge beim Erstellen eines Keys

  1. Bei platform.kimi.com anmelden und die Konsole öffnen.
  2. Zuerst ein Projekt anlegen, benannt nach Geschäftsbereich oder Umgebung, etwa crm-prod oder crm-test.
  3. Die Seite API Keys öffnen und einen Key erstellen; der Name enthält Projekt, Umgebung und Zweck.
  4. Den Key kopieren; wird er nur einmal angezeigt, sofort in den Key-Manager übernehmen.
  5. Mit GET /v1/models oder einer minimalen Anfrage Key und Seite prüfen.
  6. Verantwortlichen, Projekt, Erstellungszeit und geplantes Rotationsdatum dokumentieren.

Ein Key gehört zu einem Projekt, und der Verbrauch wird auf das Projekt gebucht; alle Projekte teilen das Guthaben und die organisatorischen Rate-Limits. Projektadministratoren können Monats- oder Tagesbudgets, TPM-Obergrenzen und SMS-Warnungen setzen. Die Budgetsperre greift mit etwa zehn Minuten Verzögerung und ist kein Echtzeit-Schalter.

Jedes Mitglied sollte einen eigenen Key erstellen. Wird ein Mitglied aus dem Projekt entfernt, verlieren seine Keys ihre Gültigkeit – das ist leichter nachzuvollziehen als ein gemeinsam genutzter Key.

4. Wo die Rechtegrenzen eines Keys liegen

Ein API Key ist kein Kontopasswort und hat keine „Allmachtsrechte“. Er kann die der Organisation zugewiesenen Schnittstellen und Modelle des Projekts aufrufen und unterliegt Projektbudget, Organisationslimits und IP-Whitelist. Bietet die Konsole keine Aufteilung von Keys nach Modell oder Schnittstelle, sollte man sie nicht voraussetzen; für Isolation dienen verschiedene Projekte, verschiedene Keys und Quoten auf Anwendungsebene.

Auch Produkte sind zu unterscheiden: Der Key von Kimi Code und ein Key der offenen Plattform sind nicht austauschbar. Ein Code-Produkt-Key an der offenen Plattform liefert häufig 401 oder 404. Mitgliederrollen, Aufladung und Rechnungsrechte sind ebenfalls getrennt; nach dem Prinzip minimaler Rechte vergeben und „kann Keys erstellen“ nicht mit „kann Abrechnung verwalten“ verwechseln.

5. Umgebungsvariablen und Ablage im Code

# .env nur lokal, nicht in das Repository einchecken
MOONSHOT_API_KEY=Ihr-Schluessel

# .gitignore enthält mindestens
.env
.env.*

In der Produktion den Secret-Manager der Plattform oder injizierte Umgebungsvariablen nutzen. In Frontend, mobilen Apps und Browser-Plugins darf kein Key erscheinen; alle Anfragen laufen über ein Backend. In Protokollen, Fehlerberichten und APM den Authorization-Header filtern und nur Key-Name oder Präfix speichern. CI/CD nutzt eigene Secrets und gibt sie nicht im Build-Log aus. Auf gemeinsam genutzten Entwicklungsrechnern erleichtert ein eigener Entwicklungs-Key pro Person die Fehlersuche.

6. 401, 403 und 429 analysieren

Bei 401 zuerst drei Dinge prüfen: Zu welcher Seite gehört der Key, passt die Base URL, und wurde der Key gelöscht oder rotiert? Danach kontrollieren, ob die Kopie vollständig ist, der Header Authorization: Bearer lautet und die Umgebungsvariable tatsächlich geladen wurde. Ein neu erstellter Key als Gegenprobe trennt schnell Key- von Konfigurationsproblemen.

403 tritt häufig auf, wenn die IP-Whitelist die aktuelle Ausgangs-IP nicht enthält oder Projektberechtigungen fehlen. Ausgangs-IPs von NAT, Proxy und Cloud Functions können von der Erwartung abweichen.

Bei 429 den Fehlertyp unterscheiden: engine_overloaded_error bedeutet serverseitige Überlast; Retry-After abwarten und Parallelität senken. rate_limit_reached_error zeigt überschrittene Organisation-RPM, -TPM, -TPD oder Parallelität. exceeded_current_quota_error deutet meist auf zu wenig Guthaben oder Zahlungsrückstand. Das OpenAI SDK wiederholt standardmäßig zweimal; eine fehlgeschlagene Anfrage kann drei Requests erzeugen – bei niedrigem Kontingent beachten.

7. Rotation, Sperrung und Umgang mit Lecks

  • Reguläre Projekte alle 90 Tage rotieren, kritische Dienste kürzer.
  • Bei Personalwechsel zuerst sperren, dann neu ausgeben; nicht nur die Zeichenkette im Code ändern.
  • Bei einem Leck sofort sperren und danach Verbrauch und Rechnung prüfen, nicht zunächst beobachten.
  • Überlappende Auslieferung: neuen Key bereitstellen und prüfen, dann den alten sperren.
  • Regelmäßig ungenutzte Keys bereinigen, damit das Mengenlimit nicht erreicht wird.
  • Protokolle enthalten nur den Key-Namen, nie den vollständigen Wert.

8. Offizieller Key oder Gateway-Key

Der offizielle Plattform-Key liegt im Konto der Kimi-API-Plattform; Abrechnung, Rechnungen und Modellbereich folgen den Plattformregeln. Er eignet sich für Teams, die ausschließlich Kimi nutzen und die direkte offizielle Schnittstelle benötigen.

Ein Gateway-Key wird im ZSQH AI Gateway erstellt; ein Key kann mehrere Modelle aufrufen, die Rechnung läuft einheitlich in Renminbi. Das eignet sich für Modellwechsel oder eine zentrale Key-Verwaltung. Verfügbare Modelle und Abrechnung richten sich nach den Modellpreisen.

Die Wege schließen einander nicht aus: Zuerst kann das Gateway zum Testen dienen, danach wird entschieden, welcher Weg in die Produktion führt. Keys nicht mischen; Base URL, Authentifizierungssystem und Guthabenkonto unterscheiden sich.

Häufige Fragen

Sind Moonshot API Key und Kimi API Key dasselbe?

Es ist derselbe Nachweis derselben offenen Plattform, nur unterschiedlich benannt. Die Plattform heißt heute Kimi API Open Platform, die Schnittstellendomain bleibt moonshot.

Warum leitet platform.moonshot.cn weiter?

Nach der Markenanpassung leitet die China-Seite auf platform.kimi.com und die internationale Seite auf platform.kimi.ai. Die API-Domains api.moonshot.cn und api.moonshot.ai sind nicht betroffen.

Lässt sich der vollständige Key nach der Erstellung erneut anzeigen?

Die meisten Plattformen zeigen ihn nur einmal bei der Erstellung; danach sind nur Name oder Präfix sichtbar. Ohne Speicherung einen neuen Key anlegen und nicht versuchen, den alten Wert wiederzufinden.

Kann ein Key für mehrere Projekte verwendet werden?

Technisch oft ja, empfehlenswert ist es nicht. Ein projektgebundener Key erleichtert Abrechnung und Limit-Zuordnung; gemeinsame Nutzung bringt Budget und Fehlersuche durcheinander.

Was tun, wenn Aufrufe nach Aktivierung der IP-Whitelist fehlschlagen?

Zuerst prüfen, ob die aktuelle Ausgangs-IP in der Liste steht, dann NAT, Proxy oder Cloud Function kontrollieren. Eine Änderung überschreibt die gesamte Liste; vor dem Speichern alle Adressen vollständig eintragen.

Nächste Schritte

Legen Sie im ZSQH AI Gateway einen Test-Key an und bringen Sie eine minimale Anfrage zum Laufen, bevor Sie Produktions-Keys nach Projekt aufteilen. Verfügbare Modelle und Abrechnung richten sich nach den Modellpreisen.

Verwandte Artikel: