API-Schlüssel
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 | Organisation | |
|---|---|---|
| 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. Organisationsschlüssel sind ein Artefakt auf Organisationsebene, das nicht an eine einzelne Person gebunden ist — ideal für Zugangsdaten, die über das Ausscheiden von Mitarbeitenden hinaus gültig bleiben und Rollenänderungen überstehen sollen.
Einen Schlüssel erstellen#
Öffne die Seite API-Schlüssel unter Einstellungen. Persönliche und Organisationsschlüssel haben jeweils eigene Tabs; der Tab Organisation ist mit Enterprise verfügbar.
Klicke auf Neuer persönlicher Schlüssel, gib ihm einen Namen (z. B. „Lokales MCP“ oder „Max' Staging-Schlüssel“) und kopiere den Schlüssel, sobald er angezeigt wird. Der Schlüssel übernimmt deine aktuelle RBAC-Rolle und deine Engine-spezifischen 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.
Organisationsschlüssel und RBAC#
Organisationsschlüssel folgen demselben Modell wie Nutzer:innen: Eine Person kann eine Rolle auf Organisationsebene haben (übergreifende Berechtigungen über Rollen & Berechtigungen) UND/ODER Engine-spezifische Berechtigungen erhalten, indem sie zu einzelnen Engines hinzugefügt wird. Ein Organisationsschlüssel funktioniert 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 du bei der Erstellung auswählst. Die Engine-Liste kannst du später bearbeiten, indem du den Schlüssel aktualisierst.
- 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
Organisationsschlüssel sind an die RBAC-Berechtigung gekoppelt. Wenn diese Berechtigung entfernt wird, werden alle Organisationsschlüssel deaktiviert — Anfragen liefern dann einen 403 und eine Meldung, die auf den Plan verweist, nicht auf den Engine-Bereich. Persönliche Schlüssel sind davon nicht betroffen. Aktiviere entweder Enterprise wieder oder wechsle 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.
- Organisationsschlüssel bringen ihre eigenen Berechtigungen mit. Änderungen an Rolle oder Bereich greifen sofort; wenn du den Schlüssel löschst, wird er widerrufen.
- Die Anzahl der Schlüssel pro Organisation ist unbegrenzt.