Authentification et portées
Authentifiez les requêtes d'API AI Glot avec des clés d'espace de travail ou des jetons OAuth, sélectionnez les portées minimales et effectuez la rotation des identifiants sans exposer vos secrets.
Transmettez une clé d’API d’espace de travail ou un jeton d’accès OAuth en tant qu’identifiant Bearer :
Authorization: Bearer aig_live_••••••••Ne placez jamais d’identifiant dans une chaîne de requête (query string). Les URL sont enregistrées dans les journaux, l’historique du navigateur et les en-têtes Referer.
Clés d’API d’espace de travail
Un administrateur crée les clés dans les Outils de développement. Le secret complet n’est affiché qu’une seule fois ; AI Glot ne conserve qu’un hachage protégé. Vous pouvez activer jusqu’à 10 clés par espace de travail.
Utilisez une clé nommée distincte pour chaque intégration.
Effectuer la rotation d’une clé
La liste des clés propose une action Rotate (Renouveler). Elle génère une clé de remplacement avec le même nom, les mêmes portées et la même date d’expiration, puis révoque la clé d’origine au cours de la même opération. L’ancienne clé cesse immédiatement de fonctionner, est marquée comme replaced au lieu d’être simplement révoquée, et conserve une trace de la clé qui lui a succédé.
Ce comportement est délibéré : vous effectuez une rotation lorsqu’un secret est potentiellement compromis, et une clé qui reste active pendant une heure supplémentaire continue de fonctionner pour quiconque l’a dérobée. Pour une transition planifiée et sans interruption de service, créez plutôt une seconde clé, basculez l’intégration dessus, assurez-vous que l’ancienne clé n’est plus sollicitée, puis révoquez-la.
Jetons OAuth
La CLI et les clients MCP compatibles peuvent utiliser OAuth 2.1. OAuth est recommandé pour une utilisation humaine, car la connexion garde une trace de la personne qui l’a approuvée et respecte le plafond d’accès de ce membre. Les clés d’API restent le choix idéal pour l’intégration continue (CI) et les services backend.
Portées
Ces portées sont disponibles dès aujourd’hui :
| Portée | Autorise |
|---|---|
account:read | Identité de l’espace de travail, forfait, fonctionnalités, limites et récapitulatif des crédits |
usage:read | Cumul d’utilisation et tranches temporelles |
batches:read | Lister les traductions, inspecter leur progression et télécharger les résultats terminés |
batches:create | Créer une traduction, la planifier et l’approuver. L’approbation consomme des crédits de l’espace de travail |
batches:write | Renommer et archiver des traductions, ou en annuler une en cours d’exécution. L’annulation facture le travail déjà effectué |
glossaries:read | Lister et récupérer des glossaires |
glossaries:write | Créer, mettre à jour, remplacer ou supprimer des glossaires |
Une portée manquante renvoie l’erreur 403 insufficient_scope.
Portées réservées
Deux portées supplémentaires peuvent être accordées dès aujourd’hui, bien qu’aucun point de terminaison ne les prenne encore en charge. Elles figurent sur l’écran de consentement OAuth et dans le préréglage Full access du tableau de bord ; elles sont donc documentées ici plutôt que masquées : toute autorisation qu’il vous est demandé d’approuver doit pouvoir être retrouvée dans la documentation de référence.
| Portée | Autorisera | Statut |
|---|---|---|
files:write | Téléverser des fichiers vers l’espace de travail lors d’une étape distincte, au lieu de les envoyer lors de l’appel de création | Pas encore disponible |
webhooks:write | Créer, modifier et supprimer les webhooks qui notifient vos systèmes dès qu’une tâche est terminée | Pas encore disponible |
Elles sont mises à disposition en amont afin qu’un identifiant accordé aujourd’hui reste opérationnel dès le déploiement de la fonctionnalité, sans nécessiter de nouvelle procédure d’approbation. Consultez la propriété capabilities sur GET /v1/account plutôt que les portées accordées pour déterminer les actions réellement possibles avec un identifiant. Une portée peut être détenue avant même que le point de terminaison associé ne soit disponible.
Plafond d’accès des membres
Les administrateurs d’un espace de travail peuvent limiter l’accès développeur des membres. Un client OAuth reçoit l’intersection de ce qu’il a demandé et de ce que le membre approbateur est autorisé à utiliser. Se reconnecter avec une requête plus large ne permet pas de contourner un plafond restreint à la lecture seule.
batches:create est exclu du plafond d’accès par défaut des membres. Toutes les autres portées sont accordées par défaut à la connexion d’un membre ; celle qui consomme des crédits ne l’est pas. Un agent tournant en boucle avec un identifiant délégué risquerait autrement d’épuiser l’intégralité du quota mensuel avant que quiconque ne s’en aperçoive, et les crédits dépensés ne peuvent pas être récupérés. Un administrateur d’espace de travail relève expressément ce plafond lorsque les traductions initiées par un agent sont souhaitées.