Die Devin API verwendet ein Principal + Token-Modell. Ein Principal ist, wer Sie sind (Ihre Identität), und ein Token ist, wie Sie das nachweisen (Ihr Berechtigungsnachweis). Diese Unterscheidung zu verstehen, ist der Schlüssel zur Wahl der richtigen Authentifizierungsmethode für Ihren Anwendungsfall.
| Principal | Token | Beschreibung |
|---|
| Service-Benutzer (nicht menschlich) | Service-Benutzer API-Key | Für automatisierte Integrationen und CI/CD-Pipelines |
| Nutzer (menschlich) | Personal Access Token (PAT) | Für programmgesteuerten Zugriff unter Ihrer eigenen Identität |
cog_. Fügen Sie Ihr Token in den Authorization-Header jeder Anfrage ein:
curl -X GET "https://api.devin.ai/v3/organizations/$DEVIN_ORG_ID/sessions" \
-H "Authorization: Bearer cog_your_token_here"
- Ein Service User API Key authentifiziert als der Service-Benutzer — es gelten die Identität, Berechtigungen und Org-Mitgliedschaften des Service-Benutzers.
- Ein Personal Access Token authentifiziert als der menschliche Nutzer, der ihn erstellt hat — es gelten die Identität, Berechtigungen und Org-Mitgliedschaften dieses Nutzers.
Service-Benutzer (empfohlen für die Automatisierung)
- Erstellen Sie einen Service-Benutzer unter Settings > Service users (Organisation) oder Enterprise settings > Service users (Enterprise)
- Weisen Sie eine Rolle zu, die steuert, auf welche Endpunkte der Service-Benutzer zugreifen kann
- Generieren Sie einen API-Key — der Schlüssel beginnt mit
cog_ und wird bei der Erstellung nur einmal angezeigt
- Verwenden Sie den Schlüssel im
Authorization-Header jeder API-Anfrage
curl -X POST "https://api.devin.ai/v3/organizations/$DEVIN_ORG_ID/sessions" \
-H "Authorization: Bearer $DEVIN_API_KEY" \
-H "Content-Type: application/json" \
-d '{"prompt": "Create a simple Python script"}'
Service-Benutzer-Geltungsbereiche
| Geltungsbereich | Erstellt unter | API-Zugriff | Anwendungsfall |
|---|
| Organization | Settings > Service users | /v3/organizations/* | Sitzungsverwaltung, Knowledge, Playbooks, Secrets |
| Enterprise | Enterprise settings > Service users | /v3/enterprise/* + /v3/organizations/* | Organisationsübergreifende Verwaltung, Analytics, Audit-Logs, Abrechnung |
Ihre Organization-ID finden Sie auf der Seite Settings > Service Users.
Sitzungszuordnung mit create_as_user_id
create_as_user_id. Die Sitzung erscheint dann in der Sitzungsliste dieses Nutzers und wird auf seine Nutzung angerechnet.
Dafür ist die Berechtigung ImpersonateOrgSessions in der Rolle des Service-Benutzers erforderlich.
- Schlüssel beginnen mit
cog_ und werden nur einmal bei der Erstellung angezeigt
- Service-Benutzer werden in Audit-Protokollen getrennt von menschlichen Benutzern aufgeführt
- Berechtigungen werden über RBAC gesteuert – weisen Sie nur die Berechtigungen zu, die die Integration benötigt
- Enterprise-Service-Benutzer erben organisationsweite Berechtigungen über alle Organisationen hinweg
Ausführliche Einrichtungshinweise finden Sie im Schnellstart für Teams oder im Schnellstart für Enterprise.
Personal Access Tokens (geschlossene Beta)
Personal Access Tokens befinden sich derzeit in der geschlossenen Beta und sind per Feature-Flag aktiviert. Kontaktieren Sie den Support, um Zugriff zu erhalten. PATs sind für SSO-/Enterprise-Konten nicht verfügbar.
Legacy-Authentifizierung (veraltet)
| Schlüsseltyp | Präfix | Verwendet mit | Beschreibung |
|---|
| Persönlicher API-Key | apk_user_ | v1, v2 | An ein Benutzerkonto gebunden, übernimmt Benutzerberechtigungen |
| Service-API-Key | apk_ | v1 | Organisationsweit gültig, für Automatisierung |
Best Practices zur Sicherheit
Geben Sie API-Schlüssel niemals in öffentlich zugänglichen Bereichen weiter, z. B. in GitHub-Repositories, clientseitigem Code oder Logs.
- Schlüssel sicher speichern: Verwenden Sie Umgebungsvariablen oder Systeme zum Secret-Management
- Schlüssel regelmäßig erneuern: Generieren Sie regelmäßig neue Schlüssel und widerrufen Sie alte
- Service-User für Automatisierung verwenden: Bevorzugen Sie Service-User gegenüber persönlichen Schlüsseln in Produktionsumgebungen
- Least-Privilege-Prinzip anwenden: Gewähren Sie nur die minimal erforderlichen Berechtigungen
- Nutzung überwachen: Prüfen Sie Audit-Logs auf unerwartete API-Aktivitäten
- Kompromittierte Schlüssel sofort widerrufen: Wenn ein Schlüssel offengelegt wurde, widerrufen Sie ihn und generieren Sie einen neuen
Mögliche Ursachen:
- Ungültige oder abgelaufene API key
- Fehlender
Authorization-Header
- Falsches Bearer-Token-Format
Lösung: Stellen Sie sicher, dass Ihre API key gültig ist und im Authorization-Header korrekt formatiert ist.
Mögliche Ursachen:
- Der API key verfügt nicht über die erforderlichen Berechtigungen
- Du verwendest den falschen Schlüsseltyp für den Endpoint (z. B. Legacy-Schlüssel mit v3-Endpoints)
- Du versuchst, auf Ressourcen außerhalb deines Zugriffsbereichs zuzugreifen
Lösung:
- Stelle sicher, dass dein Servicebenutzer die richtige Rolle und die erforderlichen Berechtigungen hat
- Für Legacy-v2-Endpoints: Stelle sicher, dass du die Enterprise-Admin-Rolle hast
- Für Legacy-v1-Endpoints: Überprüfe, ob du Zugriff auf die Organisation hast
Mögliche Ursachen:
- Falsche API-Endpunkt-URL
- Ressource existiert nicht oder Sie haben keinen Zugriff
Lösung: Überprüfen Sie die Endpunkt-URL und ob die Ressource existiert.
