Authentification
Clés Bearer, stockage sûr, restrictions et renouvellement.
L’API publique (/api/v1) accepte uniquement une clé Bearer dans l’en-tête Authorization. Les cookies et les paramètres de requête ne sont pas des moyens d’authentification valides.
Authorization: Bearer sk-spicy-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxRotation planifiée des clés
Révoquez immédiatement une clé soupçonnée de fuite, sans attendre la migration. Pour une rotation planifiée sans incident, créez une nouvelle clé, basculez l’application, vérifiez son fonctionnement, puis révoquez l’ancienne.
Envoyer la clé
Ajoutez Authorization: Bearer sk-spicy-… à chaque appel /api/v1. L’API publique, la console utilisateur et l’administration sont trois espaces d’authentification distincts : leurs identifiants ne sont pas interchangeables. Les API compatibles sous /v1 et /v1beta acceptent aussi x-api-key (SDK Anthropic) et x-goog-api-key (SDK Google GenAI). Une clé placée dans la query string de l’URL n’est jamais acceptée.
Stockage et restrictions
Conservez les clés dans votre backend ou un gestionnaire de secrets. Une clé par environnement permet de révoquer ou de renouveler l’une sans interrompre les autres.
- Fixez des plafonds de dépense quotidiens, mensuels et cumulés.
- Définissez une liste d’adresses IP autorisées si vos adresses de sortie sont fixes.
- Autorisez uniquement les modèles nécessaires et fixez des plafonds de dépense adaptés.
En cas de fuite
Désactivez immédiatement l’ancienne clé, basculez vers une nouvelle puis vérifiez taskId, request_id, IP source, modèles et dépenses dans la console. Une clé invalide renvoie HTTP 401.
Consultez le contrat OpenAPI 3.1 pour la définition complète des champs.