Devin stellt mehrere API-Versionen mit unterschiedlichen Authentifizierungsmechanismen und Autorisierungsmodellen bereit. Zu verstehen, welchen API-Key-Typ Sie verwenden sollten, ist entscheidend für eine ordnungsgemäße Integration.
Zusammenfassung der API-Versionen
| Version | Authentifizierung | Autorisierungsmodell |
|---|
| v1 | Persönliche oder Service-API Keys | Organisationsgebunden |
| v2 | Persönliche API Keys | Nur Enterprise-Admins |
| v3 (Beta) | Service-Benutzeranmeldedaten | Volles RBAC |
| API-Key-Typ | Präfix | Beschreibung |
|---|
| Persönlicher API Key | apk_user_ | API Keys mit Gültigkeitsbereich auf Benutzer- und Organisationsebene, die die individuellen Berechtigungen des Benutzers übernehmen |
| Service API Key | apk_ | Organisationsweit gültige Service API Keys für Automatisierung |
| Service-Benutzer-Anmeldedaten | cog_ | Service-Benutzer-Anmeldedaten auf Enterprise-/Organisations-Ebene mit RBAC |
- In einer beliebigen Unterorganisation zu Settings > API Keys navigieren
- Auf „Generate New API Key“ klicken
- Den Key kopieren und sicher aufbewahren (er wird nur einmal angezeigt)
Unterstützte API-Versionen:
- v1: Ja – übernimmt die Berechtigungen des Benutzers auf Org-Ebene
- v2: Ja – nur für Benutzer mit Enterprise-Admin-Rolle
- v3: Nein – stattdessen Service User Credentials verwenden
Empfohlene Anwendungsfälle:
- Persönliche Automatisierungsskripte
- Entwicklung und Tests
- Benutzerspezifische Integrationen
Sicherheitshinweise:
- Keys sind auf die Berechtigungen des Benutzers begrenzt
- Das Entziehen des Benutzerzugriffs macht dessen API-Keys automatisch ungültig
- Keys sollten regelmäßig ausgetauscht werden
Service-API-Schlüssel (Organisationsebene)
- v1: Ja – auf die Organisation beschränkt
- v2: Nein – nicht unterstützt
- v3: Nein – verwende stattdessen Service User Credentials
Empfohlene Anwendungsfälle:
- Automatisierung auf Organisationsebene
- CI/CD-Pipelines für bestimmte Teams
- Gemeinsam genutzte Tools innerhalb einer Unterorganisation
Anmeldedaten für Service User (nur v3)
- Navigieren Sie zu Enterprise Settings > Service Users
- Klicken Sie auf „Create Service User“
- Weisen Sie geeignete Rollen zu (Enterprise Admin, Org Admin, Org Member usw.)
- Generieren Sie einen API key für den Service User
Service-User-Typen:
- Enterprise Service Users: Können basierend auf den zugewiesenen Rollen auf mehrere Organisationen zugreifen
- Organization Service Users: Auf bestimmte Organisationen mit organisationsspezifischen Rollen beschränkt
Unterstützte API-Versionen:
- v1: Nein – nicht verfügbar
- v2: Nein – nicht verfügbar
- v3: Ja – vollständige RBAC-Unterstützung
Empfohlene Anwendungsfälle:
- Produktionsautomatisierung mit fein granulierten Berechtigungen
- Workflows über mehrere Organisationen hinweg
- Compliance-sensitive Integrationen, die Audit-Trails erfordern
- Langfristige Integrationen mit spezifischen Berechtigungs-Scopes
Sicherheitsaspekte:
- Service User erscheinen in Audit-Logs getrennt von menschlichen Nutzern
- Berechtigungen können präzise über RBAC gesteuert werden
- Schlüssel können rotiert werden, ohne Benutzerkonten von Menschen zu beeinträchtigen
- Ideal für das Prinzip der geringsten Rechte (Least Privilege)
Authentifizierungsmethoden
Bearer-Token-Authentifizierung
Authorization-Header an:
Authorization: Bearer your_api_key_here
curl -X POST "https://api.devin.ai/v1/sessions" \
-H "Authorization: Bearer YOUR_V1_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"prompt": "Erstellen Sie ein einfaches Python-Skript"
}'
curl -X GET "https://api.devin.ai/v2/enterprise/organizations" \
-H "Authorization: Bearer YOUR_V2_ENTERPRISE_ADMIN_KEY"
curl -X GET "https://api.devin.ai/v3beta1/enterprise/organizations" \
-H "Authorization: Bearer YOUR_V3_SERVICE_USER_KEY"
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 v3-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 die falsche API-Version für deinen Schlüsseltyp (z. B. persönlicher Schlüssel mit v3)
- Du versuchst, auf Ressourcen außerhalb deines Zugriffsbereichs zuzugreifen
Lösung:
- Für v2: Stelle sicher, dass du die Enterprise-Admin-Rolle hast
- Für v3: Verwende ein Servicebenutzer-Credential mit geeigneten Rollen
- Für v1: Ü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, ob die Endpunkt-URL mit der von Ihnen verwendeten API-Version übereinstimmt und ob die Ressource existiert.
