API-Schlüssel authentifizieren Anfragen an die Lokalisierungs-API und den MCP-Server. Lingo.dev unterstützt zwei Varianten — wählen Sie die, die am besten dazu passt, wer oder was die API aufruft.
Zwei Arten von Schlüsseln#
| Persönlich | Service | |
|---|---|---|
| Inhaber | Der Benutzer, der ihn erstellt hat | Keiner — für Automatisierung gedacht |
| Autorisierung | Übernimmt die RBAC-Rolle des Erstellers + Engine-Berechtigungen | Hat eine eigene Rolle und/oder einen Engine-Bereich |
| Wenn der Inhaber den Zugriff verliert | Verliert auch der Schlüssel den Zugriff | Nicht betroffen; gesteuert durch die eigene Rolle / den eigenen Bereich des Schlüssels |
| Plan | Jeder Plan | Enterprise (erfordert die RBAC-Berechtigung) |
| Typische Verwendung | Lokale Entwicklung, MCP, Ad-hoc-Skripte | CI/CD-Pipelines, Produktionsintegrationen |
Persönliche Schlüssel sind der Standard. Service-Schlüssel sind ein Artefakt auf Organisationsebene, losgelöst von einzelnen Personen — genau richtig für Zugangsdaten, die Mitarbeitende überdauern und Rollenänderungen standhalten sollen.
Einen Schlüssel erstellen#
Öffnen Sie im Dashboard die Seite „API-Schlüssel“. Persönliche und Service-Schlüssel haben jeweils eigene Tabs — der Tab „Service“ wird nur angezeigt, wenn Ihre Organisation den Enterprise-Plan hat.
Klicken Sie auf API-Schlüssel erstellen, vergeben Sie einen Namen (z. B. "Lokales MCP", "Max' Staging-Schlüssel") und kopieren Sie den Schlüssel aus dem Bestätigungsdialog. Der Schlüssel übernimmt Ihre aktuelle RBAC-Rolle und Ihre Engine-Berechtigungen.
Sichtbarkeit des Schlüssels
Der vollständige API-Schlüssel wird nur einmal bei der Erstellung angezeigt. Kopieren Sie ihn und bewahren Sie ihn sicher auf — nach dem Schließen des Dialogs kann er nicht mehr abgerufen werden.
Service-Schlüssel und RBAC#
Service-Schlüssel spiegeln das Benutzermodell wider: Ein Benutzer kann eine Rolle auf Organisationsebene haben (übergreifende Berechtigungen über Rollen & Berechtigungen) UND/ODER Engine-spezifische Berechtigungen erhalten, indem er zu bestimmten Engines hinzugefügt wird. Bei Service-Schlüsseln funktioniert das genauso:
- Nur Rolle — die Berechtigungen der Rolle gelten organisationsweit. Wenn sie
engine:accessenthält, kann der Schlüssel auf jede Engine in der Organisation zugreifen. - Keine Rolle + Engine-Bereich — der Schlüssel ist auf die Engines beschränkt, die Sie bei der Erstellung auswählen. Aktualisieren Sie die Liste später über die Schaltfläche Engines x/y neben dem Schlüssel.
- Rolle + Engine-Bereich — beide Berechtigungsquellen wirken additiv. Die übergreifende Rolle hat Vorrang, wenn sie
engine:accessgewährt; andernfalls gilt die Engine-spezifische Liste. - Weder noch — der Schlüssel authentifiziert sich, kann aber auf keine Engine zugreifen. Nützlich als Platzhalter, während Sie den Bereich einrichten, aber in Produktion sinnlos.
Der Anti-Eskalationsschutz greift sowohl beim Erstellen als auch beim Bearbeiten:
- Die gewählte Rolle muss zur selben Organisation gehören.
- Der Berechtigungssatz der Rolle muss eine Teilmenge von
engine:accesssein — weiter gefasste Rollen (zum Beispiel eine, dieorg:manage_teamenthält) werden abgelehnt. - Sie können eine Engine nur dann zum Bereich des Schlüssels hinzufügen, wenn Sie selbst bereits Zugriff auf diese Engine haben.
Wenn Ihr Enterprise-Plan ausläuft
Service-Schlüssel sind Teil der RBAC-Berechtigung. Wenn diese Berechtigung entfällt, werden alle Service-Schlüssel in der Organisation deaktiviert — Anfragen kommen dann mit einem 403 und einer Meldung zurück, die auf den Plan verweist, nicht auf den Engine-Bereich. Persönliche Schlüssel sind davon nicht betroffen. Stellen Sie entweder den Enterprise-Plan wieder her oder wechseln Sie zu einem persönlichen API-Schlüssel.
Einen Schlüssel verwenden#
Übergeben Sie den API-Schlüssel bei jeder Anfrage im Header X-API-Key — das Übertragungsformat ist bei beiden Varianten identisch:
curl -X POST https://api.lingo.dev/process/localize \
-H "X-API-Key: your_api_key" \
-H "Content-Type: application/json" \
-d '{"engineId": "eng_abc123", "sourceLocale": "en", "targetLocale": "de", "data": {"greeting": "Hello"}}'Derselbe Schlüssel funktioniert sowohl für die Lokalisierungs-API als auch für den MCP-Server.
Sicherheit#
- Schlüssel werden als Hashes gespeichert — Lingo.dev kann einen Schlüssel nach der Erstellung nicht wiederherstellen. Rotieren Sie ihn, indem Sie ihn löschen und neu erstellen.
- Persönliche Schlüssel folgen den Berechtigungen ihres Erstellers in Echtzeit. Wenn die Rolle des Erstellers herabgestuft oder eine Engine-Berechtigung entzogen wird, verliert der Schlüssel beim nächsten Aufruf denselben Zugriff.
- Ein persönlicher Schlüssel, dessen Ersteller aus der Organisation entfernt wurde, funktioniert nur weiter, solange RBAC deaktiviert ist (Legacy-Verhalten). Sobald RBAC aktiviert ist, wird er abgewiesen — rotieren Sie ihn, bevor er verwaist.
- Service-Schlüssel bringen ihre eigenen Berechtigungen mit. Änderungen an Rolle oder Bereich im Tab „Service“ werden sofort wirksam; das Löschen des Schlüssels widerruft ihn.
- Die Anzahl der Schlüssel pro Organisation ist unbegrenzt.
