Zum Hauptinhalt springen
GET
/
api
/
v2alpha
/
analytics
/
consumption
Verbrauchsanalysen abrufen
curl --request GET \
  --url https://server.codeium.com/api/v2alpha/analytics/consumption \
  --header 'Authorization: Bearer <token>'
{
  "data": [
    {
      "timestamp": "2026-01-15T00:00:00.000Z",
      "user_id": "user_abc123",
      "user_email": "alice@example.com",
      "consumption": {
        "prompt_credits": 1250,
        "flex_credits": 340,
        "message_count": 87
      }
    },
    {
      "timestamp": "2026-01-15T00:00:00.000Z",
      "user_id": "user_def456",
      "user_email": "bob@example.com",
      "consumption": {
        "prompt_credits": 980,
        "flex_credits": 150,
        "message_count": 52
      }
    }
  ],
  "pagination": {
    "next_page_cursor": null
  },
  "metadata": {
    "billing_strategy": "CREDITS",
    "data_freshness": "2026-01-16T03:00:00.000Z",
    "query_time_ms": 1423,
    "team_id": "team_abc123"
  }
}
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 Rate-Limit ist niedrig (10 Anfragen pro Stunde pro Team). Verwenden Sie ihn für regelmäßige Berichte und Bulk-Exporte.

​
Authentifizierung

Dieser Endpunkt verwendet die Authentifizierung per Bearer-Token. Geben Sie Ihren Service-Schlüssel im Authorization-Header an: 
Authorization: Bearer <your_service_key>
Der Service-Schlüssel muss über die Berechtigung Analytics Read verfügen. Legen Sie in Ihren Team Settings unter “Service-Schlüssel” einen an.

​
Abrechnungsstrategie

Die Antwortstruktur hängt von der Abrechnungsstrategie Ihres Teams ab:
StrategieBefüllte FelderBeschreibung
CREDITSprompt_credits, flex_creditsStandard-Teams in Enterprise SaaS
ACUbilled_acusTeams, die nach Agent Compute Units abgerechnet werden
Das Feld message_count (innerhalb von consumption) wird unabhängig von der Abrechnungsstrategie immer befüllt.

​
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
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.

​
Caching

Antworten enthalten einen ETag-Header. Um redundante Datenübertragungen zu vermeiden, senden Sie den If-None-Match-Header mit dem vorherigen ETag-Wert — der Server gibt 304 Not Modified zurück, wenn sich die Daten nicht geändert haben.

​
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“.

Header

​
If-None-Match
string

ETag-Wert aus einer vorherigen Antwort. Wenn sich die Daten nicht geändert haben, gibt der Server 304 Not Modified zurück.

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 von Dimensionen, nach denen die Ergebnisse gruppiert werden. Unterstützte Dimensionen:

  • user — enthält in jeder Zeile user_id und user_email
  • model_uid — enthält in jeder Zeile model_uid
  • ide — enthält in jeder Zeile ide
​
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