- Authentifier les requêtes auprès de Novita AI avec une clé API Bearer.
- Créer une clé API depuis la console et la stocker en toute sécurité.
- Configurer votre clé comme variable d’environnement sous Linux, macOS et Windows.
- Comprendre combien de temps une clé reste valide et ce que l’OpenAPI couvre ou ne couvre pas.
Authentication
Novita AI authentifie l’accès à l’API à l’aide de l’authentification Bearer. Envoyez votre clé API dans leAuthorization en-tête de requête:
Créer une clé API
1
Ouvrir la gestion des clés
Accédez à Gestion des clés dans la console.
2
Créer une nouvelle clé
Sélectionnez Créer une clé API, puis donnez à la clé un nom qui reflète son objectif, tel que
production ou local-testing.3
Copier et stocker la clé
La clé complète n’est affichée qu’une seule fois, lors de sa création. Copiez-la immédiatement et stockez-la dans un endroit sûr, comme un gestionnaire de secrets ou une variable d’environnement. Si vous la perdez, vous ne pouvez pas la récupérer — créez plutôt une nouvelle clé.
Si vous le souhaitez, vous pouvez limiter les modèles qu’une clé est autorisée à appeler. Consultez Accès aux modèles pour les clés API.
Format et validité des clés
- Chaque clé commence par le
sk_préfixe. - Une clé n’est affichée en entier qu’une seule fois, lors de sa création. Ensuite, la console affiche une forme masquée.
- Une clé reste valide indéfiniment une fois créée. Elle continue de fonctionner jusqu’à ce que vous la supprimiez dans la console.
- Chaque compte peut créer jusqu’à 10 clés API.
Ce que couvre l’OpenAPI
Vous créez et supprimez les clés API uniquement dans la console. La Novita OpenAPI n’inclut pas d’endpoints pour créer ou supprimer des clés. Les endpoints OpenAPI liés aux clés couvrent la liste des clés et la gestion de la stratégie d’accès aux modèles d’une clé :- Lister les clés API — répertorie les clés de votre équipe, avec un résumé facultatif de l’accès aux modèles.
- Obtenir la politique d’accès aux modèles de la clé API — lire la politique d’accès aux modèles d’une clé donnée.
- Définir la politique d’accès aux modèles de clé API — définir ou mettre à jour la politique d’accès aux modèles d’une clé.
- Réinitialiser la politique d’accès aux modèles de la clé API — réinitialise la politique d’accès aux modèles d’une clé à la valeur par défaut. Cela réinitialise uniquement la politique ; cela ne supprime pas la clé elle-même.
Stocker votre clé comme variable d’environnement
Coder une clé en dur dans le code source risque de la divulguer, par exemple lorsque vous validez le fichier. Lire la clé depuis une variable d’environnement telle queNOVITA_API_KEY le garde hors de votre code.
Temporaire vs. permanent
Un jeu de clés avecexport (Linux/macOS) ou set (Windows) ne dure que pendant la session de terminal actuelle et disparaît lorsque vous la fermez. Cela convient pour un test rapide. Pour conserver la clé d’une session à l’autre, définissez-la de façon permanente comme indiqué ci-dessous, puis ouvrez un nouveau terminal afin que la modification prenne effet.
La variable est définie mais le code ne parvient toujours pas à la trouver
Vous l’avez définie temporairement et avez ouvert un nouveau terminal
Vous l’avez définie temporairement et avez ouvert un nouveau terminal
Une clé définie avec
export ou $env: n’existe que dans la session de terminal où vous l’avez exécutée. Un nouveau terminal, ou un nouvel onglet, n’en hérite pas. Définissez la clé de façon permanente (>> ~/.zshrc, setx), ou réexécutez le export/$env: ligne dans la session que vous utilisez.Vous l’avez défini de façon permanente, mais vous n’avez pas redémarré
Vous l’avez défini de façon permanente, mais vous n’avez pas redémarré
Une modification permanente (profil de shell,
setx) s’applique aux terminaux démarrés après la modification. Ouvrez un nouveau terminal et redémarrez votre IDE ou éditeur afin qu’il prenne en compte le nouvel environnement. Sous Windows, setx n’affecte pas les terminaux déjà ouverts.Un gestionnaire de services n’hérite pas de votre environnement de shell
Un gestionnaire de services n’hérite pas de votre environnement de shell
Les processus lancés par
systemd, supervisor, Docker ou un runner CI ne lisent pas votre profil de shell interactif. Définissez la variable dans la configuration propre au service (par exemple, un systemd de l’unité Environment=, un docker run -e indicateur, ou les secrets du projet CI), pas dans ~/.bashrc.Vous avez exécuté la commande avec sudo
Vous avez exécuté la commande avec sudo
sudo ne transmet pas votre environnement par défaut, donc la variable que vous avez exportée dans votre session utilisateur n’est pas visible par le processus avec privilèges élevés. Utilisez sudo -E pour préserver l’environnement, ou définissez la variable dans le contexte avec élévation de privilèges.Articles connexes
- Accès aux modèles pour les clés API — restreindre les modèles qu’une clé peut appeler.
- Codes d’erreur courants — résoudre
401et403réponses liées aux clés. - Limites de débit — limites de requêtes et de jetons qui s’appliquent à votre compte.