Guide de la clé API Moonshot : plateforme, permissions et sécurité (2026)

De nombreux développeurs cherchent « clé API Moonshot », ouvrent platform.moonshot.cn et se retrouvent sur un autre domaine, au point de croire qu'ils se sont trompés de site. La marque de la plateforme a en réalité été ajustée : Moonshot est la marque de la société et de la plateforme ouverte, Kimi celle des modèles, et le domaine des requêtes API reste moonshot. Cet article décrit l'entrée réelle en 2026, les niveaux de compte, les permissions des clés, leur stockage, la rotation et le diagnostic des 401.

Note : Moonshot et Kimi sont des marques de leurs titulaires. Cet article est une présentation technique de l'intégration. L'entrée de la plateforme, les exigences de vérification et les règles de gestion des clés peuvent évoluer : référez-vous aux pages actuelles de la console.

I. Où se trouve désormais la plateforme Moonshot

platform.moonshot.cn redirige actuellement vers platform.kimi.com, et le site international platform.moonshot.ai vers platform.kimi.ai. La console, les comptes, les soldes et les clés sont gérés dans la plateforme Kimi API.

Le domaine des requêtes API, lui, ne change pas : api.moonshot.cn pour le site chinois, api.moonshot.ai pour l'international. Certains anciens tutoriels n'ont changé que les captures de la console sans expliquer ce point, ce qui donne l'impression que la plateforme a disparu.

Retenez trois niveaux : Moonshot est la marque de la plateforme, Kimi la marque des modèles, api.moonshot.* le domaine des interfaces. Ce ne sont pas trois comptes distincts. Les comptes, soldes et clés du site chinois et du site international sont isolés ; la clé et le site doivent être associés.

II. Choisir d'abord le type de compte : non vérifié, personnel ou entreprise

État de vérification	Projets max.	Clés API max.	Cas d'usage
Non vérifié	1	10	Essai de courte durée
Vérifié personnel	20	50	Développement individuel, petite équipe
Vérifié entreprise	50	100	Projets et membres multiples

Ces chiffres proviennent de la documentation actuelle ; la console peut les ajuster. Un compte entreprise vérifié peut inviter des membres, attribuer des permissions par projet et facturer ; un compte personnel vérifié ne peut pas inviter de membres. Les règles de changement d'entité dépendent de la console : déterminez avant l'inscription si vous utilisez une entité personnelle ou une société, car un changement ultérieur touche souvent contrat et facturation.

La couche organisation dispose aussi d'une liste blanche d'IP, disponible pour les organisations vérifiées personnelles et entreprises. Elle s'applique à l'organisation entière et limite toutes ses clés en une fois : 20 adresses IPv4 publiques ou CIDR au maximum, sans IPv6 ni adresse privée. Chaque enregistrement remplace toute la liste ; si votre IP de sortie n'est pas fixe, ne l'activez pas à la légère.

III. L'ordre correct de création d'une clé

Connectez-vous à platform.kimi.com et ouvrez la console.
Créez d'abord un projet, nommé par ligne métier ou environnement, par exemple crm-prod et crm-test.
Ouvrez la page des clés API, créez une clé et nommez-la avec projet, environnement et usage.
Copiez la clé ; si la page ne l'affiche qu'une fois, stockez-la immédiatement dans un gestionnaire de secrets.
Vérifiez la clé et le site avec GET /v1/models ou une requête minimale.
Consignez le responsable, le projet, la date de création et la date de rotation prévue.

La clé appartient au projet et la consommation y est rattachée ; tous les projets partagent le solde et les limites de l'organisation. L'administrateur de projet peut définir un budget mensuel ou journalier, un plafond TPM et des alertes SMS. Le blocage budgétaire a environ dix minutes de délai : ne le considérez pas comme un interrupteur temps réel.

Chaque membre doit créer sa propre clé. Après le retrait d'un membre du projet, les clés qu'il a créées deviennent invalides, ce qui facilite l'attribution des responsabilités par rapport à une clé partagée.

IV. Où s'arrêtent les permissions d'une clé

Une clé API n'est pas un mot de passe de compte et n'a pas de « permission universelle ». Elle peut appeler les interfaces et modèles attribués au projet par l'organisation, dans la limite du budget du projet, des limites de l'organisation et de la liste blanche d'IP. Si la console ne propose pas de clé restreinte par modèle ou par interface, ne présumez pas que l'option existe ; pour isoler, utilisez des projets et clés différents avec des quotas applicatifs.

Distinguez aussi les produits : les clés de Kimi Code et celles de la plateforme ouverte ne sont pas interchangeables. Utiliser une clé Kimi Code sur l'API de la plateforme ouverte renvoie souvent 401 ou 404. Les rôles des membres et les droits de recharge et de facturation sont également séparés : appliquez le moindre privilège et ne confondez pas « peut créer une clé » avec « peut gérer la facturation ».

V. Variables d'environnement et stockage dans le code

# .env reste en local, jamais versionné
MOONSHOT_API_KEY=votre_cle

# .gitignore doit au minimum contenir
.env
.env.*

En production, utilisez la gestion de secrets de la plateforme ou l'injection de variables d'environnement. Aucune clé dans le front-end, le mobile ou une extension de navigateur : toutes les requêtes passent par le serveur. Filtrez l'en-tête Authorization dans les journaux, les rapports d'erreur et l'APM, et ne consignez que le nom ou le préfixe de la clé. En CI/CD, utilisez un secret dédié et ne l'affichez pas dans les journaux de build. Quand plusieurs personnes partagent une machine de développement, une clé par personne facilite le diagnostic.

VI. Diagnostiquer 401, 403 et 429

Pour un 401, vérifiez d'abord trois choses : à quel site appartient la clé, si l'URL de base correspond, et si la clé a été supprimée ou renouvelée. Vérifiez ensuite que la copie est complète, que l'en-tête est bien Authorization: Bearer et que la variable d'environnement est réellement chargée. Réessayer avec une clé neuve permet de distinguer rapidement un problème de clé d'un problème de configuration.

Un 403 vient souvent d'une liste blanche d'IP qui n'inclut pas l'IP de sortie actuelle, ou de permissions de projet insuffisantes. Les IP de sortie d'un NAT, d'un proxy ou d'une fonction cloud peuvent différer de ce que vous imaginez.

Pour un 429, distinguez le type : engine_overloaded_error signale un serveur surchargé ; attendez le Retry-After et réduisez la concurrence. rate_limit_reached_error indique un dépassement des RPM, TPM, TPD ou de la concurrence de l'organisation. exceeded_current_quota_error correspond souvent à un solde insuffisant ou à un impayé. Le SDK OpenAI réessaie deux fois par défaut : un échec peut devenir trois requêtes ; les comptes à faible quota doivent y prêter attention.

VII. Rotation, révocation et gestion des fuites

Renouvelez les projets ordinaires tous les 90 jours ; les activités critiques peuvent avoir une période plus courte.
En cas de mouvement de personnel, révoquez puis réémettez ; ne modifiez pas seulement une chaîne dans le code.
En cas de fuite, révoquez immédiatement, puis examinez consommation et facturation, sans attendre.
Déploiement en chevauchement : validez la nouvelle clé avant de révoquer l'ancienne.
Nettoyez régulièrement les clés inutilisées depuis longtemps pour éviter d'atteindre le plafond.
Les journaux ne conservent que le nom de la clé, jamais la valeur complète.

VIII. Clé officielle ou clé de passerelle

La clé officielle est rattachée à un compte de la plateforme Kimi API ; règlement, facturation et périmètre des modèles suivent les règles de la plateforme. Elle convient aux équipes qui n'utilisent que Kimi et ont besoin d'un accès direct aux interfaces officielles.

La clé de passerelle se crée sur la passerelle IA ZSQH : une clé donne accès à plusieurs modèles, avec une facturation unifiée en yuans. Elle convient aux équipes qui changent de modèle ou veulent centraliser la gestion des clés. Les modèles disponibles et la facturation font foi sur Tarifs et modèles.

Les deux voies ne s'opposent pas : vous pouvez tester via la passerelle, puis décider quelle voie utiliser en production. Ne mélangez pas les clés : URL de base, système d'authentification et compte de solde diffèrent.

Questions fréquentes

Clé API Moonshot et clé API Kimi, est-ce la même chose ?

Ce sont les justificatifs d'une même plateforme ouverte, sous des appellations différentes. La plateforme s'appelle désormais Kimi API, mais le domaine des interfaces reste moonshot.

Pourquoi platform.moonshot.cn redirige-t-il ?

Après l'ajustement de marque, le site chinois redirige vers platform.kimi.com et le site international vers platform.kimi.ai. Les domaines API api.moonshot.cn et api.moonshot.ai ne sont pas affectés.

Peut-on revoir la valeur complète d'une clé après sa création ?

La plupart des plateformes ne l'affichent qu'à la création, puis seulement le nom ou le préfixe. Si vous ne l'avez pas enregistrée, créez-en une nouvelle au lieu de chercher à récupérer l'ancienne valeur.

Une clé peut-elle servir à plusieurs projets ?

Techniquement, souvent oui, mais ce n'est pas recommandé. Une clé liée à un projet facilite la facturation et l'attribution des limites ; le partage entre projets fait perdre le contrôle des budgets et du diagnostic.

Que faire si les appels échouent après activation de la liste blanche d'IP ?

Vérifiez d'abord que l'IP de sortie actuelle figure dans la liste, puis l'IP réelle du NAT, du proxy ou de la fonction cloud. La modification de la liste remplace l'ensemble : saisissez toutes les adresses avant d'enregistrer.

Pour aller plus loin

Créez d'abord une clé de test sur la passerelle IA ZSQH, validez la requête minimale, puis découpez les clés de production par projet. Les modèles disponibles et la facturation font foi sur Tarifs et modèles.

Lectures associées :