If your finance or platform team pulls Claude usage programmatically, it almost certainly uses the Usage and Cost Admin API: GET /v1/organizations/usage_report/messages for token counts and GET /v1/organizations/cost_report for spend. Both require an Admin API key (the sk-ant-admin01-... type, distinct from ordinary API keys), and both support grouping — the usage endpoint by dimensions including api_key_id, workspace_id, model, and service_tier. Grouping is what makes chargeback possible: one team per workspace, one service per key, and the report writes itself.
Until it doesn't. Anthropic's documentation names three cases where the attribution columns come back empty or the data simply isn't in this API. None of them is a bug, and each has a workable answer.
Gap 1: Workbench usage returns api_key_id: null
The Workbench is the Console's interactive playground. Requests made there are real, billed requests — but they aren't made with any of your provisioned API keys, so when you group usage by api_key_id, Workbench traffic lands in a bucket where the key ID is null.
Workaround: treat the null-key bucket as a first-class category, not noise. Label it "Console / Workbench" in your dashboards, and watch its size. A small, steady null bucket usually just means developers experimenting. A large or growing one means meaningful spend is happening outside your key-based governance — a prompt to move that work behind provisioned keys where limits and attribution apply.
Gap 2: The default workspace appears as workspace_id: null
Every organization has a default workspace, and usage that runs there is reported with workspace_id: null rather than a real ID. If your chargeback model maps workspaces to teams, anything left in the default workspace becomes unattributable — and it's often the oldest, busiest keys that live there, because they predate your workspace structure.
Workaround: make the default workspace deliberately boring. Create a named workspace per team or product, issue keys from those workspaces, and migrate production traffic out of the default one. Then treat workspace_id: null rows the same way you treat the null key bucket: a visible "unassigned" line whose target size is zero. Note also that workspace-level spend and rate limits can't be configured on the default workspace, which is one more reason production traffic shouldn't live there.
Gap 3: Per-user Claude Code costs need a different API
Claude Code usage does flow through the organization's usage and cost totals, but the Usage and Cost Admin API can't break it down by individual user. Anthropic documents that per-user Claude Code breakdowns require the separate Claude Code Analytics API. The Console dashboards have the same ceiling — Anthropic's support documentation states it isn't currently possible to break down usage or cost by individual users there either.
Workaround: if "which engineers are spending what on Claude Code" is a question you need answered, plan for two integrations from the start — the Usage and Cost API for organization-wide reporting, and the Claude Code Analytics API for developer-level detail. Don't try to reverse-engineer per-user figures from key-level data; keys are shared too often for that to hold up.
Two boundary notes before you build
First, this API exists for Claude API organizations only — it is unavailable for individual accounts, and Claude Enterprise (claude.ai) organizations use the separate Claude Enterprise Analytics API instead. Second, the whole API is a first-party Console feature: on Claude Platform on AWS the programmatic endpoints are not currently available (see why the Usage and Cost API is unavailable on Claude Platform on AWS), and on Bedrock, Vertex AI, and Foundry you use each cloud's native metering instead. Data freshness is good where it does exist — usage typically appears within about five minutes, with polling supported at up to once per minute.
Where to go next
For the full list of grouping dimensions and filters, see the Usage API dimensions and filters guide; for spend-side mechanics, see the cost endpoint deep dive. The platform overview covers where each observability surface lives.