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