← Entwickler-Anleitungen

Holen Sie sich Ihren API-Schlüssel

Erstellen Sie eine Organisation und eine Anwendung in der Console, und holen Sie sich die client_id und das client_secret, die Sie zum Aufrufen des SDK benötigen.

Jeder SDK-Aufruf benötigt Zugangsdaten. Dieser Leitfaden verschafft Ihnen die client_id und das client_secret, die Sie im nächsten Leitfaden — Ihr erster SDK-Aufruf — benötigen, in etwa zwei Minuten.

Wofür client_id und client_secret da sind

Das client_id/client_secret-Paar, das Sie unten erhalten, sind Basic-Auth-Zugangsdaten für POST /auth/token — der empfohlene Weg, um die kurzlebigen, nutzerbezogenen Session-JWTs zu erstellen, die Ihr Browser-SDK verwendet (siehe Wählen Sie Ihren Auth-Modus). Ihr backend sendet sie als Authorization: Basic base64(client_id:client_secret); die Plattform gibt ein JWT zurück, das auf die allowed_pipelines Ihrer Anwendung beschränkt ist.

Sie sind nicht dieselbe Zugangsdaten wie der x-api-key, der im reinen Server-API-Schlüssel-Modus verwendet wird, und sie sind kein JWT-Signing-Secret. Wenn Sie den (veralteten, alternativen) Self-Signed-JWT-Ansatz aus Integrieren Sie es in Ihren eigenen Server verwenden, benötigt dieser Pfad ein anderes Secret — ein pro Anwendung vergebenes Signing-Secret —, das überhaupt nicht aus diesem Console-Ablauf ausgestellt wird. Es wird außerhalb dieses Flusses vom Plattformbetreiber über einen sicheren Kanal bereitgestellt und wird nur benötigt, wenn Sie sich bewusst dafür entscheiden, selbst zu signieren, anstatt POST /auth/token aufzurufen.

Was ist mit einem statischen x-api-key?

Dieser Leitfaden behandelt das client_id/client_secret-Paar für den Session-JWT-Modus — den empfohlenen Weg für die meisten Integrationen. Ein statischer x-api-key ist ein separates, selbstbedienbares Credential für dieselbe Anwendung: Öffnen Sie die Detailseite der Anwendung in der Console und klicken Sie auf Regenerate API Key unter der Karte „API Key”. Der Schlüssel wird nur einmal angezeigt; speichern Sie ihn im Secrets-Speicher Ihres Servers.

Anders als client_id/client_secret (das Sie über POST /auth/token gegen ein kurzlebiges JWT eintauschen) wird ein x-api-key direkt als Header bei jedem Aufruf verwendet — kein Erstellungsschritt nötig. Er ist an dieselbe Anwendung gebunden: Er kann nur Pipelines aus der allowed_pipelines-Liste dieser Anwendung aufrufen und rechnet gegen das Org-Wallet derselben Anwendung ab, genau wie ein Session-JWT. Der Kompromiss ist die Zuordnung pro Nutzer — jeder Aufruf sieht so aus, als käme er von „der Anwendung”, nicht von einem bestimmten Nutzer. Wenn die Zuordnung pro Nutzer eine Rolle spielt, verwenden Sie stattdessen den Session-JWT-Modus. Den vollständigen Vergleich finden Sie unter Wählen Sie Ihren Auth-Modus.

1. Bei der Console anmelden

Öffnen Sie die Console und melden Sie sich an, oder erstellen Sie ein Konto (50 kostenlose Credits, keine Kreditkarte erforderlich).

2. Eine Organisation erstellen

Erstellen Sie eine Organisation. Sie werden deren Eigentümer. Die Organisation enthält Ihre Anwendungen, Ihre Nutzung und Ihre Abrechnung.

3. Eine Anwendung erstellen

Geben Sie unter Applications → New application einen Namen ein. Diese Anwendung ist die Identität, mit der Ihr Server das SDK aufruft.

4. client_id und client_secret kopieren

Sie sehen eine client_id und ein einmalig angezeigtes client_secret. Das Secret wird nur einmal angezeigt — kopieren Sie es sofort in den Secrets-Speicher Ihres Servers. Es darf niemals im Browser-Code oder in einem öffentlichen Repo landen.

5. Ein Pipeline aktivieren

Gehen Sie zu Tools, wählen Sie ein Pipeline (beginnen Sie mit translate-string), und klicken Sie auf Enable onto application. Dadurch wird es zur allowed_pipelines-Erlaubnisliste der Anwendung hinzugefügt — das SDK (und jedes über POST /auth/token erstellte JWT) kann nur Pipelines aufrufen, die Ihre Anwendung aktiviert hat.

Weiter geht’s: Ihr erster SDK-Aufruf verwendet dieses client_id/client_secret-Paar für einen echten Übersetzungsaufruf.