Skip to main content
Die v2-APIs befinden sich in der Alpha-Phase und können sich jederzeit ändern.

​
Überblick

Die Analytics-API v2 ist die nächste Generation der Devin Desktop Analytics-API. Sie stellt Verbrauchsanalysen (Credits und ACUs) über klar strukturierte REST-Endpunkte mit Filterung nach Abfrageparametern, flexibler Gruppierung, cursorbasierter Paginierung und Response-Caching bereit.
v2-Endpunkte werden derzeit unter dem Präfix /api/v2alpha bereitgestellt, während die API noch finalisiert wird. Die Base-URL ist https://server.codeium.com.

​
Was ist neu in v2

Die größte Änderung gegenüber v1 ist die Authentifizierung.

​
Authentifizierung

v2 verwendet die Bearer-Token-Authentifizierung. Übergeben Sie Ihre Zugangsdaten stattdessen im Authorization-Header statt im Request-Body:
Zwei Arten von Zugangsdaten werden akzeptiert: ein Devin Service-Benutzer-API-Schlüssel (empfohlen – derselbe cog_-Schlüssel, den Sie für die Devin API verwenden) oder ein Windsurf Service-Schlüssel.

​
Devin-Service-Benutzer-API-Schlüssel

Wenn Sie bereits Devin-Service-Benutzer verwalten, benötigen Sie keine separaten Windsurf-Zugangsdaten:
  1. Erstellen Sie unter Settings > Service users (Organisation) oder Enterprise settings > Service users (Enterprise) einen Service-Benutzer.
  2. Weisen Sie ihm eine benutzerdefinierte Rolle mit der Berechtigung Use Local Analytics API zu (die integrierte Admin-Rolle enthält sie bereits).
  3. Generieren Sie einen API-Schlüssel für den Service-Benutzer – er beginnt mit cog_.
  4. Verwenden Sie diesen Schlüssel als Bearer-Token.
Die Ergebnisse beziehen sich auf das gesamte Devin-Konto, dem der Service-Benutzer angehört, und metadata.team_id ist die Devin-Team-ID des Kontos (devin-team$<account_id>).
Der Filter group_id ist ein Konzept von Windsurf Teams und wird mit Devin-Zugangsdaten nicht unterstützt — Anfragen, die beides kombinieren, geben 400 Bad Request zurück.

​
Windsurf-Service-Schlüssel

  1. Navigieren Sie zu Ihrer Team Settings-Seite
  2. Gehen Sie zum Abschnitt „Service Keys“
  3. Erstellen Sie einen neuen Service-Schlüssel mit der Berechtigung Analytics Read
  4. Verwenden Sie den Schlüssel als Bearer-Token im Authorization-Header
Service-Schlüssel mit Gruppen-Geltungsbereich werden unterstützt — wenn der Geltungsbereich eines Schlüssels auf eine Gruppe beschränkt ist, werden die Ergebnisse automatisch auf diese Gruppe begrenzt.
Bewahren Sie diese Zugangsdaten sicher auf und legen Sie sie niemals in clientseitigem Code oder öffentlichen Repositorys offen.

​
Verfügbare Endpunkte

​
Abrechnungsmodell

Antworten richten sich nach dem Abrechnungsmodell Ihres Teams, das in metadata.billing_strategy angegeben wird:
  • CREDITS — Zeilen enthalten prompt_credits und flex_credits
  • ACU — Zeilen enthalten billed_acus
Das Feld message_count wird unabhängig vom Modell immer zurückgegeben. Listenantworten sind paginiert. Wenn weitere Daten verfügbar sind, enthält die Antwort einen pagination.next_page_cursor; übergib ihn als page_cursor-Abfrageparameter, um die nächste Seite abzurufen. Cursor verfallen nach 24 Stunden.

​
Caching

Antworten enthalten einen ETag-Header. Senden Sie ihn bei nachfolgenden Anfragen im If-None-Match-Header erneut mit, damit Sie bei unveränderten Daten ein 304 Not Modified erhalten.

​
Ratenlimits

Diese Endpunkte sind nicht für die Nutzungsüberwachung in Echtzeit gedacht. Die Daten werden stündlich aggregiert, und das Ratenlimit ist niedrig (10 Anfragen pro Stunde pro Team). Verwenden Sie sie für regelmäßige Berichte und Massenexporte, nicht für Live-Dashboards oder das Tracking einzelner Anfragen.
v2-Endpunkte sind auf 10 Anfragen pro Stunde pro Team begrenzt. Wenn das Limit überschritten wird, wird 429 Too Many Requests mit einem Retry-After-Header zurückgegeben. Die Paginierung einer früheren Query (durch Folgen eines next_page_cursor) wird nicht auf das Ratenlimit angerechnet — nur die anfängliche Query für jeden Bericht. Das niedrige Limit zeigt, dass diese Endpunkte für regelmäßige Berichte gedacht sind, nicht für die Überwachung in Echtzeit.