> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Analytics-API v2

> Analytics-API der nächsten Generation für die Abfrage von Verbrauchsdaten mit Bearer-Token-Authentifizierung, flexibler Gruppierung und cursorbasierter Paginierung.

<Warning>
  Die v2-APIs befinden sich in der **Alpha**-Phase und können sich jederzeit ändern.
</Warning>

<div id="overview">
  ## Überblick
</div>

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.

<Note>
  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`.
</Note>

<div id="whats-new-in-v2">
  ## Was ist neu in v2
</div>

Die größte Änderung gegenüber [v1](/de/desktop/accounts/api-reference/analytics-api-introduction) ist die **Authentifizierung**.

|                   | v1 Analytics-API                       | v2 Analytics-API                                    |
| ----------------- | -------------------------------------- | --------------------------------------------------- |
| Transport         | `POST` mit einem JSON-Request-Body     | `GET` mit Abfrageparametern                         |
| Authentifizierung | `service_key`-Feld **im Request-Body** | **`Authorization: Bearer <service_key>`-Header**    |
| Berechtigung      | Variiert je nach Endpunkt              | **Analytics Read**                                  |
| Paginierung       | Keine                                  | Cursor-basiert (`next_page_cursor` / `page_cursor`) |
| Caching           | Keines                                 | `ETag` + `If-None-Match` (`304 Not Modified`)       |

<div id="authentication">
  ## Authentifizierung
</div>

v2 verwendet die **Bearer-Token**-Authentifizierung. Übergeben Sie Ihren Service-Schlüssel stattdessen im `Authorization`-Header
statt im Request-Body:

```
Authorization: Bearer <your_service_key>
```

Der Service-Schlüssel muss die Berechtigung **Analytics Read** haben.

<div id="creating-a-service-key">
  ### Erstellen eines Service-Schlüssels
</div>

1. Navigieren Sie zu Ihrer [Team Settings-Seite](https://windsurf.com/team/settings)
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

<Warning>Bewahren Sie Ihre Service-Schlüssel sicher auf und legen Sie sie niemals in clientseitigem Code oder öffentlichen Repositorys offen.</Warning>

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.

<div id="available-endpoints">
  ## Verfügbare Endpunkte
</div>

| Endpunkt                                                                                                                          | Beschreibung                                                                                  |
| --------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| [Credit- oder ACU-Nutzung abrufen](/de/desktop/accounts/api-reference/get-consumption) (`GET /api/v2alpha/analytics/consumption`) | Nutzung von Credits oder ACUs mit Filtern, Gruppierung, Granularität und Paginierung abfragen |
| [Aktive Nutzer abrufen](/de/desktop/accounts/api-reference/get-active-users) (`GET /api/v2alpha/analytics/active-users`)          | Eindeutige aktive Nutzer zählen, optional nach Tag/Monat oder je Nutzer                       |

<div id="billing-strategy">
  ## Abrechnungsmodell
</div>

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.

<div id="pagination">
  ## Paginierung
</div>

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.

<div id="caching">
  ## Caching
</div>

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.

<div id="rate-limits">
  ## Ratenlimits
</div>

<Warning>
  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.
</Warning>

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.