Obtenez votre clé API
Créez une organisation et une application dans la Console, et obtenez le client_id et le client_secret que vous utiliserez pour appeler le SDK.
Chaque appel au SDK nécessite des identifiants. Ce guide vous procure le client_id et le
client_secret que vous utiliserez dans le guide suivant — Votre premier appel
SDK — en environ deux minutes.
À quoi servent client_id et client_secret
La paire client_id/client_secret que vous obtenez ci-dessous constitue des identifiants
d’authentification Basic pour POST /auth/token — la façon recommandée de créer les session JWT
de courte durée, par utilisateur, que votre SDK côté navigateur utilise (voir Choisissez votre
mode d’authentification). Votre backend les envoie sous la
forme Authorization: Basic base64(client_id:client_secret) ; la plateforme retourne un JWT
portant la liste d’autorisation allowed_pipelines de votre application.
Ce ne sont pas les mêmes identifiants que la x-api-key utilisée en mode clé API côté serveur
uniquement, et ce n’est pas un signing secret de JWT. Si vous optez pour l’approche héritée
(alternative) d’auto-signature de JWT décrite dans Intégrez dans votre propre
serveur, ce chemin nécessite un secret différent —
un signing secret propre à l’application — qui n’est pas du tout délivré par ce parcours de la
Console. Il est fourni hors bande par l’opérateur de la plateforme, via un canal sécurisé, et
n’est nécessaire que si vous choisissez délibérément l’auto-signature plutôt que d’appeler
POST /auth/token.
À propos d’une x-api-key statique
Ce guide couvre la paire client_id/client_secret pour le mode session JWT — la voie recommandée
pour la plupart des intégrations. Une x-api-key statique est un identifiant distinct, en
libre-service, pour la même application : ouvrez la page de détail de l’application dans la
Console et cliquez sur Regenerate API Key sous la carte « API Key ». La clé n’est affichée
qu’une seule fois ; conservez-la dans le gestionnaire de secrets de votre serveur.
Contrairement à client_id/client_secret (que vous échangez contre un JWT de courte durée via
POST /auth/token), une x-api-key s’utilise directement en tant qu’en-tête sur chaque appel —
sans étape de création. Elle est rattachée à la même application : elle ne peut appeler que les
pipelines de la liste allowed_pipelines de cette application, et est facturée sur le portefeuille
d’organisation de cette application, tout comme un session JWT. Le compromis porte sur
l’attribution par utilisateur — chaque appel semble provenir de « l’application », pas d’un
utilisateur en particulier. Pour tout ce qui nécessite une attribution par utilisateur, utilisez
plutôt le mode session JWT. Voir Choisissez votre mode
d’authentification pour la comparaison complète.
1. Connectez-vous à la Console
Ouvrez la Console et connectez-vous, ou créez un compte (50 crédits gratuits, sans carte requise).
2. Créez une organisation
Créez une organisation. Vous en devenez le propriétaire. L’organisation regroupe vos applications, votre utilisation et votre facturation.
3. Créez une application
Dans Applications → New application, donnez-lui un nom. Cette application est l’identité que votre serveur utilisera pour appeler le SDK.
4. Copiez votre client_id et client_secret
Vous verrez un client_id et un client_secret à usage unique. Le secret n’est affiché qu’une
seule fois — copiez-le immédiatement dans le gestionnaire de secrets de votre serveur. Il ne doit
jamais atteindre le code du navigateur ni un dépôt public.
5. Activez un pipeline
Rendez-vous dans Tools, choisissez un pipeline (commencez par translate-string), et
cliquez sur Enable onto application. Cela l’ajoute à la liste d’autorisation allowed_pipelines de
l’application — le SDK (et tout JWT créé via POST /auth/token) ne peut appeler que les pipelines
que votre application a activés.
Suivant : Votre premier appel SDK utilise cette paire
client_id/client_secret pour effectuer un véritable appel de traduction.