Chaque requête à l’API doit prouver qui l’émet et à quels moteurs de l’organisation elle peut accéder. Lingo.dev gère cela avec un seul en-tête sur chaque requête : X-API-Key. Il n’y a ni échange de jeton, ni session, ni mécanique OAuth à contourner par script : vous ajoutez le même en-tête aussi bien à un appel synchrone localize qu’à la soumission d’une tâche asynchrone.
Cette simplicité a toutefois un revers qu’il vaut mieux connaître avant votre premier appel : la clé est liée à l’organisation et affichée une seule fois. Cette page explique à quoi ressemble cet en-tête, ce à quoi la clé donne accès et où la stocker. Pour voir ce que l’API renvoie quand l’en-tête est incorrect, consultez Erreurs et codes d’état.
Vous découvrez l’API ?
Commencez par la Vue d'ensemble pour l’URL de base et le modèle mental du moteur. Cette page part du principe que vous avez déjà une clé API depuis le tableau de bord et que vous avez simplement besoin de l’envoyer.
L’en-tête#
Envoyez votre clé dans l’en-tête X-API-Key à chaque requête :
X-API-Key: your_api_keyEn situation, le même en-tête accompagne tous les endpoints, synchrones comme asynchrones :
curl https://api.lingo.dev/jobs/localization \
-H "X-API-Key: your_api_key" \
-H "Content-Type: application/json" \
-d '{
"sourceLocale": "en",
"targetLocales": ["de", "ja"],
"data": { "greeting": "Welcome aboard" }
}'Avec une clé valide, vous obtenez la réponse normale de l’endpoint — ici, un 202 avec un groupId. Si l’en-tête est manquant ou invalide, l’API renvoie 401 ; cette réponse, ainsi que tous les autres codes, est documentée sur la page Erreurs.
Ce à quoi une seule clé donne accès#
Une clé appartient à une organisation, pas à un moteur en particulier. Une seule clé donne accès à tous les moteurs de localisation de cette organisation : inutile donc de créer un identifiant distinct par moteur. Le même X-API-Key fonctionne que vous cibliez votre moteur marketing ou votre moteur de documentation, et vous pouvez omettre engineId pour utiliser le moteur par défaut de l’organisation.
Cette portée est pratique, mais c’est aussi le point à bien mesurer : une clé compromise donne accès à tout ce que l’organisation peut atteindre. Traitez-la donc comme n’importe quel secret de production. Chargez-la depuis une variable d’environnement ou un gestionnaire de secrets, ne la versionnez jamais et conservez-la côté serveur — la clé sert à authentifier les appels effectués depuis votre backend, pas depuis un navigateur où n’importe qui pourrait la lire. La même règle s’applique à l’interface temps réel WebSocket : elle s’authentifie avec la même clé, donc ces connexions doivent elles aussi être ouvertes côté serveur.
Générez et gérez vos clés dans la section API Keys du tableau de bord.
Stockée une fois, ou jamais#
La clé n’est affichée qu’une seule fois, au moment de sa création. Une fois cette fenêtre fermée, il n’est plus possible de la récupérer.
Copiez votre clé avant de quitter la page
Les clés API ne s’affichent qu’une seule fois lors de leur création. Stockez la clé dans votre gestionnaire de secrets ou votre environnement dès qu’elle apparaît — vous ne pourrez plus la récupérer ensuite. Si une clé est perdue ou si vous pensez qu’elle a été compromise, générez-en une nouvelle dans le tableau de bord API Keys.
C’est l’un des rares cas où la voie la plus simple est aussi la plus sûre : bien stocker la clé dès sa création est à la fois la solution la plus rapide et la seule qui évite qu’une intégration de production se retrouve bloquée derrière un identifiant que personne ne peut relire.
Prochaines étapes#
Vous pouvez désormais authentifier n’importe quel appel. Deux sujets s’enchaînent naturellement : comprendre ce qui est renvoyé lorsqu’une requête est rejetée, et voir quels endpoints cet en-tête vous ouvre.
