Zum Hauptinhalt springen
Diese Seite dokumentiert Änderungen, die speziell für die Devin-APIs (v1, v2 und v3) gelten. Versionshinweise zur Anwendung finden Sie unter Application Release Notes.

​
2025

​
Dezember 2025
v3 API-Updates
  • Session-Archiv-Endpunkt (11. Dez.): Endpunkt POST /v3beta1/organizations/{org_id}/sessions/{devin_id}/archive zum Archivieren von Sessions hinzugefügt. Außerdem wurde der Query-Parameter archive zu DELETE /v3beta1/organizations/{org_id}/sessions/{devin_id} (Session beenden) und das Feld is_archived zu Session-Antworten hinzugefügt.
  • Entfernung des Order-Parameters (11. Dez.): Breaking Change: Der Query-Parameter order wurde aus dem Sessions-Listenendpunkt (GET /v3beta1/organizations/{org_id}/sessions) entfernt. Clients dürfen order nicht mehr senden; verwenden Sie stattdessen Cursor-basierte Paginierung mit den Parametern first/after.
  • Unterstützung für Advanced Sessions (8. Dez.): Unterstützung für erweiterte Session-Modi (analyze, create, improve, batch, manage) mit neuen Request-Parametern hinzugefügt: advanced_mode, child_playbook_id, session_links und bypass_approval. Session-Antworten enthalten jetzt die Felder child_session_ids, parent_session_id und is_advanced.
  • Searches-Router (10. Dez.): Enterprise- und organisationsweite Search-Endpunkte unter GET /v3beta1/enterprise/searches und GET /v3beta1/organizations/{org_id}/searches zum Auflisten von Suchvorgängen mit Paginierung und Filterung hinzugefügt.
  • Verbesserungen bei Audit-Logs (10. Dez.): data-Objekt sowie die Felder service_user_name und user_email zu Audit-Log-Antworten hinzugefügt. update_git_permission als neuen Action-Typ hinzugefügt.
  • Session-Tags-Router (5. Dez.): CRUD-Endpunkte unter /v3/beta/enterprise/organizations/{org_id}/tags hinzugefügt, um zulässige Session-Tags pro Organisation zu verwalten. Wenn die Tag-Validierung aktiviert ist, erzwingen Session-Erstellung und Tag-Updates, dass nur Tags aus der zulässigen Liste verwendet werden.
  • Enterprise-Sessions-Endpunkt (5. Dez.): GET /v3/beta/enterprise/sessions hinzugefügt, um Sessions im gesamten Enterprise mit optionalem org_ids-Filter aufzulisten.
  • Git-Berechtigungsupdates (5. Dez.): prefix_path-Feld zum Abgleichen von Repositories anhand eines Pfadpräfixes hinzugefügt. PUT- und DELETE-Endpunkte für das Bulk-Ersetzen oder Leeren aller Berechtigungen für eine Organisation hinzugefügt.
  • Session-Impersonation (5. Dez.): Parameter create_as_user_id zum Session-Erstellungsendpunkt hinzugefügt, sodass Service-Benutzer Sessions im Namen anderer Benutzer erstellen können.
  • Änderung der Hypervisors-Antwort (5. Dez.): Die Antwort des Hypervisors-Endpunkts gibt jetzt utilization_percentage statt max_slots und available_slots zurück.
  • Notes- und Playbooks-Router (1. Dez.): Enterprise- und organisationsweite Notes- und Playbooks-Management-Endpunkte zur v3 API hinzugefügt. Notes-Endpunkte erfordern die Berechtigung ManageAccountKnowledge, Playbooks-Endpunkte erfordern die Berechtigung ManageAccountPlaybooks.
v2 API-Updates
  • Messages-Feld für Sessions (11. Dez.): Feld messages zur v2-Sessions-API-Antwort hinzugefügt, das alle Session-Nachrichten bereitstellt, ähnlich wie in der v1 API.
  • Verbesserungen am Response-Schema (11. Dez.): Eigene Response-Schemas für Audit-Logs-, Snapshot- und Playbook-Endpunkte hinzugefügt, einschließlich AuditLogsResponse, EnterpriseSnapshotResponse und EnterprisePlaybookResponse.
v1 API-Updates
  • Abkündigung der Audit-Logs (5. Dez.): Der Endpunkt /v1/audit-logs ist veraltet; verwenden Sie stattdessen die v2- oder v3-Audit-Logs-Endpunkte.
​
November 2025
v2 Enterprise API-Updates
  • Update des Pagination-Limits (21. Nov.): Maximales Pagination-limit von 1000 auf 200 Elemente pro Anfrage reduziert, um Performance und Zuverlässigkeit zu verbessern. Das Standard-limit bleibt 100. Diese Änderung betrifft NICHT die v1 External API.
  • Sessions-Router (16. Nov.): Umfassende Sessions-Management-Endpunkte zur v2 API für Enterprise-Administratoren hinzugefügt.
  • Snapshots-API-Endpunkt (3. Nov.): Endpunkt zum programmatischen Abrufen von Snapshot-Details hinzugefügt.
v1 API-Updates
  • Endpunkt zum Beenden von Sessions (31. Okt.): Endpunkt hinzugefügt, um laufende Sessions programmatisch zu beenden.
​
Oktober 2025
v3 API-Launch (Beta)
  • API v3 Launch (23. Okt.): v3 API mit vollständiger RBAC-Unterstützung, Service-Benutzer-Authentifizierungsmodell und umfassendem Audit-Logging für Aktionen von Service-Benutzern gestartet.
v2 Enterprise API-Updates
  • Endpunkt zur Snapshot-Erstellung (30. Okt.): Neuer v2 Enterprise Organizations API-Endpunkt für Enterprise-Admins, um Repositories programmatisch zu klonen und Snapshots mit benutzerdefinierten Setup-Schritten und Startbefehlen zu erstellen.
  • Verbesserungen an der Playbooks-API (14. Okt.): API zum Veröffentlichen von Enterprise-Playbooks mit verbesserter Funktionalität für das programmatische Playbook-Management hinzugefügt.
​
September 2025
v2 Enterprise API-Updates
  • Roles-Router (25. Sep.): Enterprise-Roles-Router mit fünf API-Endpunkten zum programmatischen Verwalten von Rollen hinzugefügt.
v1 API-Updates
  • Playbooks-API (6. Sep.): Umfassende Playbooks-API-Endpunkte in v1 hinzugefügt, um Playbooks programmatisch zu erstellen, zu aktualisieren, aufzulisten und zu löschen.
  • Secrets-Endpunkt (5. Sep.): Neuer POST /v1/secrets-Endpunkt zum Erstellen von Secrets über die API hinzugefügt.
​
März 2025
v2 Enterprise API-Launch
  • API v2 Launch (23. März): Enterprise API v2 für Enterprise-Administratoren mit Funktionen für Organisationsverwaltung, Verbrauchsverfolgung und Mitgliederverwaltung gestartet.

​
2024

​
Oktober 2024
Einführung der v1-API (26. Okt.)
  • REST-API für die programmgesteuerte Erstellung und Verwaltung von Sitzungen eingeführt
  • Endpunkte für Erstellung, Überwachung und Verwaltung von Sitzungen
  • Unterstützung für das Hoch- und Herunterladen von Dateianhängen
  • Einfache Authentifizierung mit API keys
  • Unterstützung für idempotente Sitzungserstellung
  • Anwendungsfälle: automatische Reviews von Pull Requests (PRs), Behebung von Lint-Fehlern, Migrationen

​
API-Versionsrichtlinie

​
Abwärtskompatibilität

Wir bemühen uns, innerhalb einer Hauptversion die Abwärtskompatibilität sicherzustellen. Nicht abwärtskompatible Änderungen werden:
  1. mindestens 7 Tage im Voraus angekündigt
  2. in diesen Versionshinweisen dokumentiert
  3. gegebenenfalls durch Migrationsleitfäden ergänzt

​
Abkündigungsprozess

Wenn wir eine API-Funktion abkündigen:
  1. Ankündigung: Wir kündigen die Abkündigung mit einem Zeitplan an
  2. Abkündigungszeitraum: Die Funktion bleibt verfügbar, ist aber als veraltet gekennzeichnet
  3. Entfernung: Die Funktion wird nach Ablauf des Abkündigungszeitraums entfernt

​
Version-Support

  • v1: Allgemein verfügbar, wird aktiv gewartet
  • v2: Allgemein verfügbar, wird aktiv gewartet
  • v3: Beta – Änderungen vorbehalten, für den Produktionseinsatz noch nicht empfohlen

​
Migrationsleitfäden

​
Migration von v1 auf v3

Wenn Sie neue Integrationen mit fein granulierten Berechtigungen erstellen, sollten Sie v3 statt v1 verwenden: Wesentliche Unterschiede:
  • Authentifizierung: v3 erfordert Service-User-Tokens statt persönlicher/servicebezogener API keys
  • Autorisierung: v3 bietet vollständiges RBAC mit rollenbasierten Berechtigungen
  • Endpoints: v3 verwendet andere URL-Muster (/v3beta1/* statt /v1/*)
Migrationsschritte:
  1. Erstellen Sie unter Enterprise Settings > Service Users einen Service User
  2. Weisen Sie dem Service User geeignete Rollen zu
  3. Generieren Sie einen API key für den Service User
  4. Aktualisieren Sie Ihre Integration, damit sie die v3-Endpoints verwendet
  5. Testen Sie alles gründlich in einer Nicht-Produktionsumgebung
v3 API-Dokumentation ansehen →

​
Migration von v2 auf v3

v3 bietet mehr Flexibilität als v2 für Enterprise-Automatisierung: Wesentliche Unterschiede:
  • Authentifizierung: v3 verwendet Service-Benutzer anstelle persönlicher Schlüssel von Enterprise-Administratoren
  • Autorisierung: v3 unterstützt granuläres RBAC anstelle von ausschließlich Enterprise-Admin-Zugriff
  • Geltungsbereich: v3 kann auf bestimmte Organisationen beschränkt werden, v2 gilt immer unternehmensweit
Wann Sie migrieren sollten:
  • Sie benötigen Automatisierung mit Berechtigungen unterhalb der Admin-Ebene
  • Sie möchten den API-Zugriff auf bestimmte Organisationen begrenzen
  • Sie benötigen eine klare Trennung zwischen menschlichen Konten und Servicekonten
  • Sie benötigen detaillierte Audit-Protokolle für automatisierte Aktionen

​
Support

Bei Fragen zu API-Änderungen oder zur Unterstützung bei der Migration: