Chaque requête porte un jeton bearer. Il existe deux types de clés, distingués par leur préfixe, et utiliser le mauvais est l’erreur la plus fréquente au départ.
Authorization: Bearer <votre clé>
Les deux types
ar-v1-…— inférence. Envoie des requêtes aux modèles. C’est celle qui va dans votre application.ar-mgmt-…— gestion. Administre le compte : clés, justificatifs de fournisseur, garde-fous, crédits. Elle ne peut pas envoyer de requête d’inférence.
Cette séparation est délibérée. Une clé d’inférence est déployée largement — dans des conteneurs, en intégration continue, sur le portable d’un client — et si elle pouvait énumérer vos justificatifs de fournisseur, chacun de ces endroits deviendrait un moyen de les atteindre.
Traitement des clés
- Les clés sont conservées sous forme d’empreinte salée. Nous ne pouvons pas en récupérer une, et le soutien technique non plus.
- Une nouvelle clé est affichée une seule fois, à sa création.
- La révocation prend effet en quelques secondes. Les dépenses antérieures restent à votre charge.
- Fixez un plafond de dépenses sur chaque clé. C’est ce qui borne le coût d’une fuite.
Gérer les clés
GET/v1/keys
POST/v1/keys
DELETE/v1/keys/:hash
Les trois exigent une clé de gestion.
Vérifier une clé
GET/v1/key
Retourne l’enregistrement de la clé appelante — étiquette, type, plafond, utilisation. Utile comme vérification qu’une clé déployée est toujours active.
curl
curl https://autonomousrelay.com/v1/key -H "Authorization: Bearer $AUTONOMOUSRELAY_API_KEY"