Skip to main content
GET
Verbrauchsanalysen abrufen
Dies ist ein v2-Endpunkt, der Bearer-Token-Authentifizierung und Abfrageparameter verwendet, im Gegensatz zur v1 Analytics-API, die Service-Schlüssel im Request-Body verwendet. Siehe unten Authentifizierung.
Dieser Endpunkt ist 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 ihn für regelmäßige Berichte und Bulk-Exporte.

Authentifizierung

Dieser Endpunkt verwendet die Bearer-Token-Authentifizierung. Geben Sie Ihr Token im Authorization-Header an:
Verwenden Sie entweder einen Devin-Service-Benutzer-API-Schlüssel mit der Berechtigung Use Local Analytics-API oder einen Windsurf- Service-Schlüssel mit der Berechtigung Analytics Read. Unter Authentication erfahren Sie, wie Sie beide erstellen.

Abrechnungsstrategie

Die Antwortstruktur hängt von der Abrechnungsstrategie Ihres Teams ab: Die Felder message_count und user_message_count (innerhalb von consumption) werden unabhängig von der Abrechnungsstrategie zurückgegeben. user_message_count zählt nur Nachrichten, die ein Nutzer an den Agent gesendet hat – unabhängig davon, über welchen Client (Devin Desktop, das JetBrains-Plugin oder die CLI); der Wert entspricht der Anzahl „gesendeter Nachrichten“ in der Analytics-UI. message_count zählt jedes Abrechnungsereignis, einschließlich der Folgeanfragen an Modelle und Tools innerhalb jeder Eingabe. user_message_count ist null für Zeilen ohne Zuordnung zu Nutzernachrichten (Nutzung vor dem 11.04.2026).

Gruppierung und Granularität

Verwenden Sie granularity und group_by, um die Struktur der zurückgegebenen Daten zu steuern:
  • Keine Granularität oder Gruppierung — gibt eine einzelne aggregierte Zeile für den gesamten Datumsbereich zurück
  • granularity=daily — jede Zeile enthält einen timestamp im Format YYYY-MM-DD
  • granularity=monthly — jede Zeile enthält einen timestamp im Format YYYY-MM
  • group_by=user — jede Zeile enthält eine user_id und user_email
  • group_by=user,model_uid — jede Zeile enthält user_id, user_email und model_uid
  • group_by=ide — jede Zeile enthält ein ide
  • group_by=ide,ide_version — jede Zeile enthält ide und ide_version (für die Gruppierung nach ide_version muss auch ide enthalten sein)
  • group_by=os — jede Zeile enthält ein os, wie z. B. darwin (macOS), windows oder linux
Um zu messen, was der Agent erzeugt hat – statt was er verbraucht hat –, verwenden Sie Get Output (metric=loc_inserted,loc_deleted). Dieser Endpunkt gibt akzeptierte Codezeilen mit denselben Filtern und Gruppierungsdimensionen zurück.

Paginierung

Die Ergebnisse sind paginiert, mit einer Standardseitengröße von 1.000 Zeilen (max. 10.000). Wenn weitere Ergebnisse verfügbar sind, enthält die Antwort im Objekt pagination einen next_page_cursor. Übergeben Sie ihn als page_cursor-Abfrageparameter, um die nächste Seite abzurufen. Page-Cursor laufen nach 24 Stunden ab. Eine nachfolgende Seitenanfrage zählt nicht als neue Abfrage für Ihr Rate-Limit.

Anfragelimits

Dieser Endpunkt ist auf 10 Anfragen pro Stunde pro Team begrenzt. Wenn dieses Limit überschritten wird, gibt der Server 429 Too Many Requests mit einem Retry-After-Header zurück. Die Paginierung einer früheren Abfrage (über einen next_page_cursor) wird nicht auf dieses Limit angerechnet — nur die erste Abfrage für jeden Bericht. Das niedrige Limit spiegelt wider, dass dieser Endpunkt für periodische Berichte gedacht ist, nicht für die Nutzungsüberwachung in Echtzeit.

Autorisierungen

Authorization
string
header
erforderlich

Ein Service-Schlüssel mit der Berechtigung Analytics Read, übergeben als Bearer-Token im Header Authorization.

Erstellen Sie einen Service-Schlüssel in Ihren Team Settings im Abschnitt „Service Keys“.

Abfrageparameter

start_date
string<date>
erforderlich

Beginn des Datumsbereichs (einschließlich) im Format YYYY-MM-DD.

end_date
string<date>
erforderlich

Ende des Datumsbereichs (einschließlich) im Format YYYY-MM-DD. Der Bereich darf 90 Tage nicht überschreiten.

product
enum<string>
erforderlich

Produkt, für das Verbrauchsdaten abgefragt werden sollen.

Verfügbare Optionen:
agent
granularity
enum<string>

Zeitgranularität für die Gruppierung der Ergebnisse. Wenn angegeben, enthält jede Zeile ein Feld timestamp. Wenn nicht angegeben, werden die Ergebnisse über den gesamten Datumsbereich aggregiert.

Verfügbare Optionen:
daily,
monthly
group_by
string

Kommagetrennte Liste der Dimensionen, nach denen die Ergebnisse gruppiert werden. Unterstützte Dimensionen:

  • user — enthält user_id und user_email in jeder Zeile
  • model_uid — enthält model_uid in jeder Zeile
  • ide — enthält ide in jeder Zeile
  • ide_version — enthält ide_version in jeder Zeile; setzt voraus, dass auch ide enthalten ist
  • os — enthält os in jeder Zeile
models
string

Kommagetrennte Liste von Modell-UIDs, auf die die Ergebnisse gefiltert werden sollen.

group_id
string

Filtert die Ergebnisse auf Nutzer in einer bestimmten Gruppe. Der Service-Schlüssel muss Zugriff auf diese Gruppe haben.

user_id
string

Filtert die Ergebnisse auf einen bestimmten Nutzer (Auth-UID).

page_size
integer
Standard:1000

Maximale Anzahl von Zeilen, die pro Seite zurückgegeben werden.

Erforderlicher Bereich: 1 <= x <= 10000
page_cursor
string

Opaker Cursor aus pagination.next_page_cursor einer vorherigen Antwort, um die nächste Seite abzurufen.

Antwort

Verbrauchsdaten erfolgreich zurückgegeben.

data
object[]
erforderlich

Array von Zeilen mit Verbrauchsdaten.

pagination
object
erforderlich
metadata
object
erforderlich