Skip to main content
The v2 APIs are in alpha and subject to change at any time.

​
Overview

Analytics API v2 is the next generation of the Devin Desktop Analytics API. It exposes consumption analytics (credits and ACUs), active users, and agent output (accepted lines of code) through clean REST endpoints with query-parameter filtering, flexible grouping, and cursor-based pagination.
v2 endpoints are currently served under the /api/v2alpha prefix while the API surface is finalized. The base URL is https://server.codeium.com.

​
What’s new in v2

The biggest change from v1 is authentication.

​
Authentication

v2 uses Bearer token authentication. Pass your credential in the Authorization header instead of in the request body:
Two kinds of credential are accepted: a Devin service user API key (recommended — the same cog_ key you use for the Devin API) or a Windsurf service key.

​
Devin service user API keys

If you already manage Devin service users, you do not need separate Windsurf credentials:
  1. Provision a service user under Settings > Devin API (Service users tab) for an organization, or Enterprise settings > Devin API (Service users tab) for the enterprise
  2. Assign it a custom role that includes the Use Local Analytics API permission (the built-in admin role already includes it)
  3. Copy the API key shown after provisioning — it starts with cog_
  4. Use that key as the Bearer token
Results cover the whole Devin account the service user belongs to, and metadata.team_id is the account’s Devin team identifier (devin-team$<account_id>).
The group_id filter is a Windsurf teams concept and is not supported with Devin credentials — requests that combine the two return 400 Bad Request.

​
Windsurf service keys

  1. Navigate to your team settings page
  2. Go to the “Service Keys” section
  3. Create a new service key with the Analytics Read permission
  4. Use the key as a Bearer token in the Authorization header
Group-scoped service keys are supported — when a key is scoped to a group, results are automatically limited to that group.
Keep these credentials secure and never expose them in client-side code or public repositories.

​
Available endpoints

​
Billing strategy

Consumption responses adapt to your team’s billing strategy, reported in metadata.billing_strategy (output and active-user responses are unaffected):
  • CREDITS — rows include prompt_credits and flex_credits
  • ACU — rows include billed_acus
The message_count (billing events) and user_message_count (user-sent messages, null for usage before 2026-04-11) fields are always returned regardless of strategy.

​
Pagination

List responses are paginated. When more data is available, the response includes a pagination.next_page_cursor; pass it back as the page_cursor query parameter to fetch the next page. Cursors expire after 24 hours.

​
Rate limits

These endpoints are not intended for real-time usage monitoring. Data is hourly-aggregated and the rate limit is low (10 requests per hour per team). Use them for periodic reporting and bulk export, not live dashboards or per-request tracking.
v2 endpoints are rate-limited to 10 requests per hour per team. Exceeding the limit returns 429 Too Many Requests with a Retry-After header. Paginating an earlier query (following a next_page_cursor) does not count against the rate limit — only the initial query for each report does. The low limit reflects that these endpoints are for periodic reporting, not real-time monitoring.