Claude Code Analytics Admin API does not return subscription/OAuth users

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/9700
2. https://github.com/anthropics/claude-code/issues/20819

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

we are seeing a similar issue, and this makes it really hard to understand spending. would be great to have this resolved

Tripling down on this.... Went to build a spending reporting app and was shocked to find this information isn't available

Same issue here: OAuth/subscription users are still missing from the Analytics Admin API on our side too, so this is clearly not an isolated case. At this point, months of silence and auto-closed reports make it look less like a bug and more like a deceptive, self-serving failure to provide basic transparency.

I'm finding it frustratingly difficult to get basic per user usage/cost data for Enterprise subscriptions. Wouldn't most every organization be needing this? Are people solving this in some other way? This API would seem the simple answer to my needs, but...it doesn't work as advertised.

Here's a response I got from Anthropic in January:

Claude.ai (where Pro and Team plans live) and the API Console at platform.claude.com are completely separate platforms with independent account systems and separate data stores. This is why your org IDs are different between the two platforms. They are distinct organizations, even if you use the same email address for both. The Admin API key you created from platform.claude.com/settings/admin-keys is scoped to your Console API organization, so it can only return data for users within that Console organization, and cannot reach into claude.ai subscription organizations to retrieve that data. This is an architectural limitation, not a configuration issue on your end.

@holkeri Do you know if is possible to bring the metrics information for claude.ai subscription? Because the only way to create a API key admin is inside platform.claude.com/settings/admin-keys website.

I did not find any other way to create an admin key in claude.ai.

@matheuspalhares-ar, The way I understand it, the Analytics API doesn't support claude.ai.

Here's Anthropic's response to my follow-up question:

>1. Why do the API docs at https://platform.claude.com/docs/en/build-with-claude/claude-code-analytics-api#dimensions say "subscription for Pro/Team customers" if the API doesn't support

Pro/Team customers?

Ah good callout, that's actually incorrect information, I'll flag that to the docs team to get updated.

We need this too. Or at least add an export functionality to the cost explorer in claude.ai. It's been too hard to track usage since we moved to an enterprise plan.

+1

Adding a Team-plan perspective on the same root problem — per-user usage visibility for non-API-key (subscription/OAuth) users.

Team plan admins are hit harder than Enterprise, because we don't have access to the Admin API at all. Our only tools are two CSV exports from the admin Analytics page, and both are structurally unable to answer "who uses heavily?" and "who doesn't use their seat?":

1. Spend Report CSV — overage-only. Users within their seat quota appear as $0 or are absent entirely. No date column.
2. Claude Code team export — Lines this Month only. Silently undercounts every non-coding use case (security review, threat modeling, architecture design, pentest analysis, code critique, documentation, planning).

The data clearly exists — the admin Analytics page renders daily aggregate charts (unique users, sessions, lines of code per day) that can only be computed from per-user daily data. It's just not exposed at per-user granularity anywhere a Team plan admin can reach.

Concrete example from my team this month (identifiers redacted):

| Metric | Value |
|---|---:|
| Lines of code this month | 63 |
| Overage spend (90 days) | $76.56 — highest on team |
| Requests | 660 |
| Prompt tokens | ~84M |

By the Lines export this user barely exists. By the Spend export they look like the most reckless spender on the team. Reality: heavy, legitimate non-coding usage (review, design, threat modeling). No export I have access to can represent this user honestly — and this is exactly the kind of user an admin most needs visibility into for capacity and budget planning.

The pattern across #9700, #20819, and now this issue is consistent: per-user usage for subscription/OAuth users is the single most-requested admin gap, and each prior issue has been auto-closed without an Anthropic response. Would appreciate even a one-line acknowledgement on direction here — is this on the roadmap, declined, or still unscoped?

For what it's worth, the Team-plan version of this ask is small in scope: a per-user, per-day CSV export (email, date, product, model, requests, tokens, sessions) on the existing admin Analytics page would be sufficient. No API required.

+1 We have a lot of developers on subscription plan that we can't track if the seat is being used correctly since all our usage reports are $0.00 for them. They are also missing in the tokens report. We have gone completely blind metrics-wise.

+1 The teams plan is lacking token level and model level metrics. API access to non-platform accounts would be great. fwiw @denisurbanavicius cost data for individuals on teams is available here:

https://claude.ai/api/claude_code/metrics_aggs/users?start_date=2026-04-01&end_date=2026-04-30&limit=10&offset=0&sort_by=total_lines_accepted&sort_order=desc&organization_uuid=<org uuid>&customer_type=claude_ai&subscription_type=team

Inserting your org_uuid (and assuming you're logged in). This is the endpoint the Claude Code analytics dashboard uses, it does return course spend data that isn't currently rendered in the UI.

@chanian That worked! Thank you so much!

I've been able to fetch per user cost metrics via:

https://api.anthropic.com/v1/organizations/analytics/user_cost_report

    -H "x-api-key: $ANALYTICS_KEY" \
    -H "anthropic-version: 2023-06-01" \
    --data-urlencode "starting_at=$START" \
    --data-urlencode "ending_at=$END" \
    --data-urlencode "group_by[]=product" \
    -d "limit=1000" \

You can create an analytics API key which is different from the admin API key from claude.ai/analytics/api-keys.

EDIT: I also found this article. Seems like this endpoint has not been documented yet in the API reference or at least I did not find it.

@damyan-hristov-t212 Does your org have an Enterprise account? That api-keys provisioning page doesn't seem to exist on individual or teams account. If so, yes - these specific api endpoints are seemingly available to enterprise users only.

+1

+1 from a 123-person org on the Team plan.

We're building an internal AI-spend dashboard and want per-developer Claude Code metrics (sessions, LoC, commits, PRs, tokens) straight from the Claude Code Analytics API rather than inferring them from GitHub commit messages. The blocker is exactly this issue: our developers authenticate Claude Code via their claude.ai subscription seats (OAuth), and the /v1/organizations/usage_report/claude_code endpoint returns only customer_type: "api" records — so our entire developer population is invisible to the API.

The public docs list customer_type: subscription and user_actor (OAuth) as supported, which contradicts the behaviour reported here. Could you clarify whether subscription-seat coverage is (a) intended and buggy, or (b) intentionally Enterprise-only? For mid-sized orgs on Team this is the difference between having real Claude Code adoption data and having none.

The risky part here is not just missing rows, but that the omission is silent. A usage dashboard consuming GET /v1/organizations/usage_report/claude_code will naturally read "no subscription/OAuth rows" as "zero usage", which is very different from "this population is not covered by this credential/API."

A more robust contract would make coverage explicit:

• Response-level included_customer_types and excluded_customer_types, with machine-readable reasons.
• Explicit customer_type on every row.
• Stable user_actor identity for OAuth users, ideally email where the admin surface permits it, otherwise a stable hashed user id.
• Stable subscription org/workspace id, so platform API orgs and claude.ai/team workspaces can be reconciled.
• Clear plan/admin-surface requirements for each population.
• Row- or response-level source / coverage fields so consumers can distinguish API-key, subscription, Enterprise-only, unavailable, and partially-covered data.

If subscription/OAuth Claude Code usage is intentionally unavailable for a given admin key, returning that as structured metadata, or as a 4xx / feature_not_enabled response, would be much safer than returning an empty-looking report.

One implementation lesson from ax: local transcript and OTLP ingestion can recover useful per-machine analytics like sessions, tools, cost, latency, churn, and routing. But provider-side user/org identity and coverage boundaries are exactly the pieces local tooling cannot reconstruct reliably.

Concrete ask: either include subscription/OAuth Claude Code rows in this report, or make the response self-describing about why those users are excluded.

---

_Generated with ax._

Does anyone have an estimated timeline for when this issue will be resolved?

+1 from a Team-plan org (AI Reserve, ~8 seats). Probe from our org today (2026-08-13), admin key, GET /v1/organizations/usage_report/claude_code?starting_at=2026-08-01: exactly 1 record for all of August — our CI api_actor — and zero customer_type: "subscription" records, despite ~$1.4K of seat-based Claude Code usage this month by OAuth-authenticated Team members (visible in the claude.ai Teams admin usage page, so the data clearly exists server-side). The docs list user_actor/subscription as supported, which is why we built our internal spend tooling against this endpoint — the gap between docs and behavior cost us a build cycle. If subscription-seat coverage is Enterprise-only by design, documenting that would save other Team orgs the same detour; if it's a bug, happy to test against our org the day a fix ships.

@ashwin-aireserve this endpoint is for enterprise accounts only. the admin api key you provisioned for your console account is not tied to your sub account.

thanks, that explains our probe. quick follow up, is team plan coverage for this endpoint roadmapped or is it enterprise only for good? if its the latter a small enterprise note in the docs would save other team orgs the same detour, they currently list user_actor and subscription as supported record types which is what sent us down this path. happy to sanity check against our team org if coverage ever ships

@ashwin-aireserve this is indirectly implied / documented here: https://platform.claude.com/docs/en/manage-claude/admin-api-keys
the provisioning of the necessary API key is restricted to console, and enterprise plans. I agree with you, this could be presented much clearer. DM me on X (same username) if you'd like to discuss work around / options here.

Great thanks Ian! sent a DM on X

For anyone blocked on this who needs the data now rather than whenever the API gets fixed: Claude Code's own OpenTelemetry export does cover OAuth/subscription users. It is client-side emission, so none of the Console-vs-claude.ai org splitting applies.

I pointed a bare OTLP receiver at 127.0.0.1:4318 and ran a session as an OAuth-authenticated user. Every metric point and every log record arrived carrying:

user.email
user.account_uuid
user.account_id
organization.id
session.id
terminal.type

That is the exact population /v1/organizations/usage_report/claude_code drops. claude_code.cost.usage and claude_code.token.usage carry the same attribute set, alongside session.count, lines_of_code.count, commit.count, pull_request.count and active_time.total.

Minimum config:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=http/json
export OTEL_EXPORTER_OTLP_ENDPOINT=http://your-collector:4318

Two things worth knowing before you rely on it. Admins can push this fleet-wide through managed settings rather than asking every developer to set env vars, and when the endpoint is set in managed settings Claude Code strips conflicting developer-set variables at startup, so people cannot quietly redirect their own telemetry somewhere else. And for seat-based plans the cost number is imputed from tokens rather than billed, so it answers "who is consuming the pool" and "who is not using their seat," which I think is what most of this thread is actually asking. It is not invoice reconciliation.

Question for the people here who have already tried to build this internally, since several of you clearly have: is standing up and running your own collector the easy part or the annoying part? I am weighing whether a hosted endpoint plus a "you are 80% through the month and one developer is 60% of it" alert is worth anything to you, or whether pointing this at Grafana yourself is genuinely fine and the only real problem here is that the Admin API should just work. Straight answers welcome, including "we would never route telemetry to a third party."