Skip to main content

​
Überblick

Personal Access Tokens (PATs) ermöglichen es menschlichen Nutzern, sich programmgesteuert mit ihrer eigenen Identität zu authentifizieren. Im Gegensatz zu API-Schlüsseln für Service-Benutzer (die als nicht menschlicher Service-Benutzer authentifizieren) authentifiziert ein PAT als Sie selbst — als der menschliche Nutzer, der den Token erstellt hat. Alle API-Anmeldedaten verwenden das Präfixformat cog_. Beide Token-Typen werden im Authorization-Header auf identische Weise verwendet:

​
Geltungsbereich und Berechtigungen

Ein PAT gehört Ihnen und Ihrem Konto (Ihrem Teams-Konto oder Ihrem Enterprise). Es ist nicht an eine einzelne Organisation gebunden, und es gibt kein „Organisations-PAT“ oder „Enterprise-PAT“. Das unterscheidet es von Service-Benutzern, die entweder auf Organisations- oder Enterprise-Ebene erstellt werden. Jede Anfrage legt die Organisation fest. Organisations-Endpunkte geben sie im URL-Pfad an (/v3/organizations/{org_id}/...), und die Anfrage wird anhand Ihres Zugriffs und Ihrer Rolle in dieser Organisation autorisiert. Eine Anfrage für eine Organisation, auf die Sie keinen Zugriff haben, schlägt fehl. Das Token hat dieselben Berechtigungen wie Ihr Nutzer. Alles, was Sie in der Web-App tun können, können Sie auch mit Ihrem PAT tun – und nichts darüber hinaus. Um PATs zu erstellen, zu rotieren oder zu widerrufen, benötigen Sie Manage API keys in der Organisation, deren Settings Sie gerade anzeigen, oder API-Schlüssel für Konten verwalten auf Kontoebene. Diese Berechtigung bestimmt, wer Tokens verwalten kann; sie ändert nicht, was ein Token tun kann. Enterprise-Konten verfügen außerdem über eine interne Organisation, in der ausschließlich unternehmensweite Settings gespeichert werden. Sie ist kein Workspace. PAT-Anfragen, die an sie gerichtet sind, werden mit 403 abgewiesen. Verwenden Sie daher immer die ID einer untergeordneten Organisation.

​
Wann Sie PATs verwenden sollten

PATs sind für Szenarien gedacht, in denen Sie als Sie selbst programmgesteuerten API-Zugriff benötigen:
  • Persönliche Skripte und Tools — automatisieren Sie Ihre eigenen Workflows ohne einen gemeinsam genutzten Service-Benutzer
  • Lokale Entwicklung — testen Sie API-Integrationen mit Ihrem eigenen Konto
  • Kurzlebige Automatisierung — einmalige Skripte, die Ihnen zugeordnet werden sollen
Für Produktionsintegrationen, CI/CD-Pipelines und gemeinsam genutzte Automatisierung verwenden Sie stattdessen API-Schlüssel für Service-Benutzer. Service-Benutzer bieten bessere Audit-Trails, eine zentrale Schlüsselverwaltung und RBAC-Kontrollen. Wenn Sie sich nicht sicher sind, welche Option Sie verwenden sollen, lesen Sie den Vergleich.

​
PATs erstellen und verwalten

Verwalten Sie Ihre PATs im Tab PATs auf der Settings-Seite Devin API, in jeder Organisation oder in den Enterprise-Settings. Der Tab zeigt in beiden Fällen dieselben Token an (siehe Geltungsbereich und Berechtigungen).
  1. PAT erstellen — geben Sie ihm einen Namen und ein Ablaufdatum. Das Token beginnt mit cog_ und wird bei der Erstellung nur einmal angezeigt.
  2. Token verwenden im Authorization-Header — genau wie einen API-Schlüssel für Service-Benutzer. Jeder API-Aufruf wird mit Ihrem Nutzerkonto authentifiziert: Ihre Berechtigungen, Organisationsmitgliedschaften und Ihr Audit-Trail gelten.
  3. PAT rotieren — generieren Sie ein neues Secret für ein bestehendes Token, ohne dessen Namen zu ändern; das alte Secret funktioniert sofort nicht mehr.
  4. PAT widerrufen — machen Sie das Token jederzeit ungültig.
PATs werden auch von Echtzeit-Endpunkten wie dem ACP-Live-WebSocket akzeptiert, sodass Tools wie die Devin CLI und Desktop-Clients sich mit einem PAT authentifizieren können.

​
Governance auf Enterprise-Ebene

In Enterprise-Konten wird die Verfügbarkeit von PATs durch eine unternehmensweite PAT-Richtlinie gesteuert, die für alle Organisationen des Enterprise-Kontos gilt. Enterprise-Admins mit Enterprise-Settings verwalten konfigurieren die Richtlinie (und bearbeiten Genehmigungsanfragen) auf der Registerkarte PAT-Richtlinien auf der Enterprise-Settings-Seite für die Devin API.

​
Richtlinienmodi

​
Ablaufrichtlinie

Wenn PATs für ein Enterprise aktiviert sind, muss jedes PAT ein Ablaufdatum haben. Die maximale Gültigkeitsdauer wird durch die Richtlinie festgelegt (standardmäßig 365 Tage; Admins können eine kürzere Obergrenze konfigurieren). Nicht-Enterprise-Konten (Teams) können PATs ohne Ablaufdatum erstellen.

​
Genehmigungsworkflow

Bei Genehmigung erforderlich:
  1. Ein Member beantragt auf dem Tab „PATs“ einen PAT (Name + Ablaufdatum).
  2. Enterprise-Admins sehen den Antrag in der Genehmigungswarteschlange und genehmigen oder lehnen ihn ab.
  3. Nach der Genehmigung schließt der Member den Antrag ab, um den Token zu erstellen (er wird nur einmal angezeigt).
  4. Ausstehende Anträge verfallen automatisch nach 7 Tagen, wenn sie nicht bearbeitet werden.
Antragstellende und Admins werden bei jedem Schritt im Token-Lifecycle (beantragt, genehmigt, abgelehnt, widerrufen) per E-Mail benachrichtigt.

​
Tokenbestand und Widerruf

Enterprise-Admins mit API-Schlüssel für Konten verwalten können:
  • Alle PATs anzeigen, einschließlich ihres Compliance-Status gemäß der aktuellen Richtlinie
  • Tokens gebündelt widerrufen (z. B. nach einer Verschärfung der Richtlinie)
Eine Verschärfung der Richtlinie (oder das Deaktivieren von PATs) storniert betroffene ausstehende Anfragen. Der Bestand kennzeichnet außerdem vorhandene Tokens, die nicht mehr konform sind.

​
Automatischer Entzug

Die PATs eines Nutzers werden automatisch widerrufen, wenn seine Mitgliedschaft im Account endet – auch bei Entzug über die SCIM-Deprovisionierung oder Änderungen an IdP-Gruppen.

​
Sicherheitshinweise

  • Behandeln Sie PATs mit derselben Sorgfalt wie Passwörter — sie gewähren vollständigen Zugriff auf Ihr Konto
  • Speichern Sie PATs in Umgebungsvariablen oder Secret-Managern, niemals im Quellcode
  • Legen Sie die kürzeste für Ihren Anwendungsfall geeignete Gültigkeitsdauer fest
  • Widerrufen Sie PATs sofort, wenn sie kompromittiert wurden
  • Bevorzugen Sie API-Schlüssel für Service-Benutzer für gemeinsam genutzte oder produktive Automatisierungen

​
Nächste Schritte