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) through clean REST endpoints with query-parameter filtering, flexible grouping, cursor-based pagination, and response caching.
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. Create a service user under Settings > Service users (organization) or Enterprise settings > Service users (enterprise)
  2. Assign it a custom role that includes the Use Local Analytics API permission (the built-in admin role already includes it)
  3. Generate an API key for the service user — 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

Responses adapt to your team’s billing strategy, reported in metadata.billing_strategy:
  • CREDITS — rows include prompt_credits and flex_credits
  • ACU — rows include billed_acus
The message_count field is 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.

​
Caching

Responses include an ETag header. Send it back in the If-None-Match header on subsequent requests to receive a 304 Not Modified when the data is unchanged.

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