Anmeldedaten für Service-Benutzer (empfohlen)
- Erstellen Sie einen Service-Benutzer unter Settings > Service users
- Weisen Sie eine Rolle zu, die steuert, auf welche Endpunkte der Service-Benutzer zugreifen kann
- Generieren Sie einen API-Schlüssel (beginnt mit
cog_)
- Fügen Sie den Schlüssel in den
Authorization-Header jeder Anfrage ein
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"}'
Bereiche für Service-Benutzer
| Bereich | 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, wenn Sie eine Sitzung erstellen. 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 Users erforderlich.
Umstieg von persönlichen API keys? Persönliche API keys (v1/v2) haben Sitzungen automatisch unter Ihrem Benutzerkonto erstellt. Mit Service Usern verwenden Sie create_as_user_id für dasselbe Verhalten — mit zusätzlichem RBAC, Audit Trails und zentralem Schlüsselmanagement. Ein Beispiel finden Sie in der API-Übersicht.
- 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.
Veraltete API-Schlüssel werden zugunsten von Service-Benutzern abgeschafft. Wir empfehlen, bestehende Integrationen auf Service-Benutzer umzustellen. Siehe den Migrationsleitfaden. | Schlüsseltyp | Präfix | Verwendet mit | Beschreibung |
|---|
| Persönlicher API-Schlüssel | apk_user_ | v1, v2 | An ein Benutzerkonto gebunden, übernimmt Benutzerberechtigungen |
| Service-API-Schlüssel | apk_ | v1 | Organisationsweit gültig, für Automatisierung |
Bearer-Token-Authentifizierung
Authorization-Header an:
Authorization: Bearer your_api_key_here
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.
