- Authentifier les requêtes adressées à Novita AI avec une clé API Bearer.
- Créer une clé API dans la console et la stocker en toute sécurité.
- Définir la clé comme variable d’environnement sous Linux, macOS ou Windows.
- Vérifier combien de temps une clé reste valide et quelles opérations sur les clés l’OpenAPI prend en charge.
- Configurer les politiques d’accès aux modèles et au réseau pour une clé.
Authentification
Novita AI utilise l’authentification Bearer pour l’accès à l’API. Envoyez votre clé API dans l’en-tête de requêteAuthorization :
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 usage, tel que
production ou local-testing.3
Copier et stocker la clé
La clé complète n’est affichée qu’une seule fois, au moment de sa création. Copiez-la immédiatement et stockez-la dans un emplacement sécurisé, comme un gestionnaire de secrets ou une variable d’environnement. Si vous la perdez, vous ne pourrez pas la récupérer ; créez plutôt une nouvelle clé.
Configurer les contrôles d’accès
Les contrôles d’accès sont facultatifs et se configurent par clé API :- Accès aux modèles pour les clés API contrôle quels modèles une clé peut appeler dans la plage de modèles activée de votre équipe.
- Accès réseau pour les clés API contrôle quelles adresses IP sources peuvent utiliser une clé pour l’invocation de modèles.
Format et validité de la clé
- Chaque clé commence par le préfixe
sk_. - 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.
- Chaque compte peut créer jusqu’à 10 clés API.
Vous définissez l’expiration lorsque vous créez la clé. Elle ne peut pas être modifiée par la suite : vous ne pouvez ni renouveler une clé ni la faire expirer immédiatement. Les clés Permanent restent valides indéfiniment, de sorte qu’une clé divulguée reste utilisable plus longtemps. N’utilisez des clés permanentes que lorsque c’est approprié. L’expiration se configure uniquement dans la console ; l’OpenAPI ne crée pas de clés et ne définit, ne modifie ni ne supprime leur expiration.
Ce que couvre l’OpenAPI
Vous créez et supprimez les clés API uniquement dans la console. L’OpenAPI Novita n’a aucun point de terminaison pour créer ou supprimer des clés, et ne prend pas en charge la configuration de l’expiration d’une clé. Les points de terminaison OpenAPI liés aux clés vous permettent de lister les clés et de gérer leurs politiques d’accès aux modèles et au réseau :- Lister les clés API — liste les clés de votre équipe, avec un récapitulatif facultatif des accès aux modèles.
- Obtenir la politique d’accès aux modèles d’une clé API — lit la politique d’accès aux modèles d’une seule clé.
- Définir la politique d’accès aux modèles d’une clé API — définit ou met à jour la politique d’accès aux modèles d’une clé.
- Réinitialiser la politique d’accès aux modèles d’une 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.
- Obtenir la politique d’accès IP d’une clé API — lit la politique d’accès réseau d’une seule clé.
- Définir la politique d’accès IP d’une clé API — définit ou met à jour les adresses IP sources autorisées pour une clé.
- Supprimer la politique d’accès IP d’une clé API — efface la politique d’accès réseau d’une clé, rétablissant l’absence de restriction sur les IP sources.
Stocker votre clé comme variable d’environnement
Le fait de coder en dur une clé dans le code source peut l’exposer, par exemple lorsque vous commitez le fichier. La lire depuis une variable d’environnement telle queNOVITA_API_KEY la garde hors de votre code source.
Temporaire ou permanent
Une clé définie avecexport (Linux/macOS) ou set (Windows) ne dure que pour la session de terminal en cours et disparaît lorsque vous la fermez. Cela convient pour un test rapide. Pour conserver la clé entre les sessions, définissez-la de façon permanente comme indiqué ci-dessous, puis ouvrez un nouveau terminal pour que la modification prenne effet.
La variable est définie mais le code ne la trouve toujours pas
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 avez exécuté la commande. Un nouveau terminal ou onglet ne l’hérite pas. Définissez la clé de façon permanente (>> ~/.zshrc, setx), ou exécutez à nouveau la commande export/$env: dans la session que vous utilisez.Vous l’avez définie de façon permanente mais n’avez pas redémarré
Vous l’avez définie de façon permanente mais n’avez pas redémarré
Une modification permanente (un profil de shell ou
setx) s’applique aux terminaux démarrés après la modification. Ouvrez un nouveau terminal, puis redémarrez votre IDE ou éditeur pour qu’il puisse lire l’environnement mis à jour. Sous Windows, setx n’affecte pas les terminaux déjà ouverts.Un gestionnaire de services n’hérite pas de votre environnement shell
Un gestionnaire de services n’hérite pas de votre environnement shell
Les processus lancés par
systemd, supervisor, Docker ou un exécuteur CI ne lisent pas votre profil de shell interactif. Définissez la variable dans la configuration propre au service, par exemple l’Environment= d’une unité systemd, un flag docker run -e, ou les secrets du projet CI, plutôt que 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 une variable exportée par votre utilisateur n’est pas visible pour le processus élevé. Utilisez sudo -E pour préserver l’environnement, ou définissez la variable dans le contexte élevé.Voir aussi
- Codes d’erreur courants — résoudre les réponses
401et403liées aux clés. - Limites de débit — limites de requêtes et de jetons qui s’appliquent à votre compte.