If you're measuring Claude Code impact at the leadership level, the first question is usually whether you can get the right data out of it.
Reporting data in Claude Code is more nuanced than it first appears. Anthropic does not expose a single reporting surface. Instead, there are separate paths for aggregated Claude Code analytics, broader API usage and cost data, enterprise engagement analytics, an OpenTelemetry (OTel) export, hooks, and the local session files that Claude Code writes to disk. Each one answers a different class of questions. Choose the wrong source and the result can be the wrong level of detail, the wrong freshness, or a much larger implementation lift than the problem actually warrants.
This guide is for engineering leaders making that source decision deliberately. It is designed to clarify what data is available, which source fits each question best, and where the sharp edges are.
API: /v1/organizations/usage_report/claude_code
Who this is for
This is the cleanest source for a leadership team that wants a program-level view of Claude Code adoption and output without standing up its own telemetry stack. Anthropic positions the Claude Code Analytics API as the programmatic way to access daily aggregated Claude Code usage analytics and productivity metrics for an organization, and it sits between the basic analytics dashboard and the heavier OpenTelemetry path. It is only available through the Admin API, which is not available for individual accounts. Access requires an organization and an Admin API key created by a member with the admin role. See Anthropic's Claude Code Analytics API and Admin API overview.
What you get
Anthropic describes this endpoint as a daily, user-level Claude Code analytics feed. It returns one record per user for a specified day and includes output-oriented fields such as session counts, lines of code added and removed, commits, pull requests, tool usage, token usage, and estimated cost. For an executive audience, this is the source that most closely matches questions such as: Are people actually using Claude Code? Which teams are adopting it? Which models are they using? Is usage translating into visible engineering activity? See the official Claude Code Analytics API.
There is one subtle but important wrinkle here. Anthropic's response schema includes a customer_type field, and the example payload shows values such as api. That is useful if you need to distinguish among different commercial motions inside one organization. It also means you should not assume that every Claude Code user record represents the same billing model or deployment pattern without checking the payload in your own environment. See the response structure.
Start date of data
Anthropic says historical Claude Code analytics data is retained and accessible through the API, and it does not publish a fixed deletion period for this dataset. In practice, that makes this one of the more attractive sources for longitudinal adoption reporting because it is not explicitly capped the way some other surfaces are. Anthropic does not publish an exact retention promise, so it is safer to treat this as historically available rather than contractually indefinite unless your agreement says otherwise. See Anthropic's FAQ on data retention for the Claude Code Analytics API.
Freshness
Anthropic documents this as near-current, but not real-time. The data typically appears within about one hour of user activity completion. Keep in mind that your integration will need to ensure that you’ve retrieved all of the data for recent periods given the update frequency of this data set. That is good enough for daily operational reporting and executive review, but it is the wrong source for live dashboards or session-by-session monitoring. Anthropic explicitly says that if real-time metrics are required, OpenTelemetry is the better fit. See Anthropic's Claude Code Analytics API FAQ and Claude Code monitoring guide.
How to connect
Compared with the lower-level sources, the connection pattern is straightforward. Call the endpoint with an Admin API key in the x-api-key header and include the Anthropic version header. The main work is not authentication. The real work is deciding how the daily records should be stored, modeled, udpated, and reported once they arrive.
Important limitations
This endpoint is narrower than it first appears. Anthropic states that it only tracks Claude Code usage on the first-party Claude API. Usage on Amazon Bedrock, Google Vertex AI, or other third-party platforms is not included. That matters if your company has standardized on a cloud-provider-hosted model route and assumes the Anthropic admin surfaces will still show the full picture. They will not. See Anthropic's note on supported Claude Code deployments.
The second limitation is conceptual. This is a daily aggregate, not a raw event stream. That makes it excellent for adoption and management reporting, but it is not the right source for prompt-level reconstruction, custom policy auditing, or near-real-time operational alerting. Those use cases push you toward OpenTelemetry, hooks, or the underlying session files.
API: /v1/organizations/usage_report/messages
Who this is for
This source is best for teams that primarily care about Anthropic API consumption, cost, model mix, workspace breakdowns, and service-tier behavior. Anthropic describes it as the Usage and Cost Admin API for historical API usage and cost data. It is the right answer for questions from platform engineering, finance, or AI infrastructure teams about usage/cost for solutions which make use of the Anthopic API. It is usually not the first source to reach for when the question is specifically about Claude Code adoption. See Anthropic's Usage and Cost API.
What you get
This surface returns granular usage and cost data for the organization's API activity. Anthropic documents grouping and filtering dimensions such as model, workspace, service tier, context window, data residency, speed-beta settings, and more. It is useful when the goal is to understand where API spend is coming from, how usage changes over time, or how different model and workspace choices affect consumption. See the Usage API and Cost API.
The key thing to remember is that this is an API usage surface first. Anthropic even says that if you want per-user cost breakdowns for Claude Code, the Claude Code Analytics API is the better path than trying to force that view out of the general usage feed. That is a strong signal about intended use. See Anthropic's FAQ on per-user cost breakdowns for Claude Code.
Start date of data
Anthropic presents this as historical usage and cost data similar to what appears in the Claude Console usage and cost pages. The documentation does not use the same open-ended retention language that appears in the Claude Code Analytics API, so from a governance standpoint it is better to treat this as a historical operational dataset rather than assume permanent retention. If long-horizon trend analysis matters, it is worth pulling and storing a copy on your own cadence. See Anthropic's Usage and Cost API.
Freshness
This is the freshest of Anthropic's admin reporting APIs. Anthropic says usage and cost data typically appears within five minutes of API request completion, and it supports polling once per minute for sustained use. That makes it a good operational source for spend monitors, usage anomaly checks, and product instrumentation rollups. See Anthropic's FAQ on data freshness and polling frequency.
How to connect
Like the Claude Code Analytics API, this is part of the Admin API and requires an Admin API key. The connection pattern is straightforward. The harder part is shaping the output into something leadership can actually use, because the raw power of this API comes from grouping and filtering rather than from opinionated, ready-made executive metrics.
Important limitations
The first limitation is scope. This API is broader than Claude Code, not deeper on Claude Code. If the goal is to explain how engineers are using Claude Code specifically, this surface can tempt teams into building a proxy answer from API keys, workspaces, or model usage. Anthropic's own docs point to a different endpoint for the direct per-user Claude Code view. See Anthropic's FAQ on per-user cost breakdowns for Claude Code.
The second limitation is that some important details are split across different endpoints and fields. Anthropic notes that code execution costs appear in the cost endpoint under Code Execution Usage, but code execution is not included in the usage endpoint. It also notes that Priority Tier usage can be identified in the usage endpoint via service_tier = priority, while Priority Tier costs are not available in the cost endpoint. Those are exactly the kinds of mismatches that produce confident but wrong dashboards when nobody reads the fine print. See Anthropic's FAQ on code execution usage and Priority Tier usage.
API: /v1/organizations/analytics/users
Who this is for
This source is for Enterprise organizations that want user-level adoption and engagement reporting across Claude itself and Claude Code. It is not a general-purpose admin API. Anthropic's support documentation says you need Primary Owner access to the Enterprise organization to use the Analytics API, and the key must carry the read:analytics scope. That makes this a leadership and governance surface, not something most individual teams will wire up casually. See Anthropic's Analytics API access guide and Analytics API reference guide.
What you get
This Analytics API returns aggregated engagement metrics, raw activity events, and conversation content. That matters, when executives assume "analytics API" means "everything." It does not. See Anthropic's Analytics API access guide.
The /users endpoint returns per-user engagement metrics for a single day, and each record includes activity counts across Claude chat and Claude Code. Anthropic's reference docs show that this can include Claude Code metrics such as commit count, pull request count, and lines of code added and removed. For a senior engineering leader, this is useful when the need is an engagement lens rather than a billing or observability lens. It helps answer questions such as: Who is active? Which users are consistently engaged? Is adoption broad, or concentrated in a small cluster of heavy users? See Anthropic's Analytics API reference guide.
Start date of data
Anthropic says the Analytics API data is available for up to the past 90 days and not before January 1, 2026. That means this source is intentionally windowed. It is not a historical system of record unless you extract and retain it yourself. If quarter-over-quarter or year-over-year leadership reporting matters, this data needs to be warehoused, or the rolling window needs to be accepted as a hard limit. See Anthropic's Analytics API access guide.
Freshness
Anthropic documents a three-day delay in Analytics API availability. It also explicitly rejects requests for dates before January 1, 2026, for today, or for future dates. This is not an operational monitoring source. It is a lagged engagement and adoption source. That can still be valuable for weekly or monthly leadership reviews, but it is the wrong source for incident response, chargeback, or same-day management reporting. See Anthropic's Analytics API reference guide.
How to connect
Connection is more constrained than it is for the Admin API reporting surfaces. Anthropic's support documentation says only the Primary Owner can enable access and create the key, and every request must use a key with the read:analytics scope. In practice, the governance process is usually harder than the technical implementation.
Important limitations
The biggest limitation is that this endpoint is adoption-oriented, not cost-oriented. It gives you user engagement metrics, but it does not solve finance or real-time operational questions. It is also capped to a 90-day lookback and delayed by three days. If today-level visibility is required, this is the wrong surface. If the need is raw prompts, raw user events, or detailed observability, this is also the wrong surface. Anthropic points those use cases to other products and APIs. See Anthropic's Analytics API access guide.
There is another edge case worth calling out. Anthropic explicitly says that if Claude Code is being used through Amazon Bedrock, the Analytics API will not return Claude Code data. That kind of deployment-specific exclusion is easy to miss, and it is exactly the sort of thing that can make a rollout look smaller on paper than it really is. See Anthropic's Analytics API access guide.
OpenTelemetry data
Who this is for
OpenTelemetry is for teams that want near-real-time observability, are comfortable running their own collection pipeline, and care about detailed usage, cost, and tool-activity telemetry. This is a better fit for platform engineering, observability teams, or organizations that already operate standardized telemetry backends. Anthropic's Claude Code docs describe OpenTelemetry as the path for tracking usage, costs, and tool activity across the organization by exporting telemetry data through OTel. See Anthropic's Claude Code monitoring guide.
What you get
Anthropic says Claude Code exports metrics as time series, events through the logs/events protocol, and optionally distributed traces through the traces protocol. In other words, this is the richest forward-looking operational surface in the product. It is the best source when freshness, tool behavior, latency, and observability-grade detail matter. It is also the best source when you need to build custom alerting and engineering analytics outside Anthropic's opinionated admin views. See Anthropic's Claude Code monitoring guide.
OpenTelemetry gives you signal-level detail, but it does not give you a ready-made executive model. You still need to decide what to aggregate, what to persist, and what the organization should actually look at.
Start date of data
This is a going-forward source. Anthropic's setup is about exporting telemetry once you enable it. There is no backfill story for historical Claude Code activity through OTel. If it is turned on today, observability starts today. That makes it a poor answer for retrospective adoption analysis and a strong answer for future-state monitoring. See Anthropic's Claude Code monitoring guide.
Freshness
This is the most immediate of the standard reporting paths, but "immediate" still needs a precise definition. Anthropic's docs say the default export intervals are 60 seconds for metrics and 5 seconds for logs. That is operationally close to real time, and it is significantly fresher than the admin analytics surfaces. It is also adjustable as part of your telemetry configuration. See Anthropic's Claude Code monitoring guide.
How to connect
Telemetry is enabled in Claude Code with environment variables and exporter selection for metrics and logs. Anthropic also documents administrator configuration through the managed settings file, which allows centralized control of telemetry settings across an organization. That matters if consistency is the goal rather than hoping individual developers configure their workstations the same way. See Anthropic's Claude Code monitoring guide.
Important limitations
The first limitation is operational burden. You need your own collector, your own backend choices, your own schema discipline, and your own decisions about retention, access control, and reporting. Anthropic provides the export path, not the finished management system. See Anthropic's Claude Code monitoring guide.
The second limitation is that some of the richest tracing detail is gated. Anthropic documents additional detailed tracing behavior behind beta and feature-gated settings, and some content-bearing attributes are emitted only when detailed beta tracing is active. That matters if you assume a standard OTel rollout will automatically include the richest possible payloads. It will not. See Anthropic's Claude Code monitoring guide.
Hooks
Who this is for
Hooks are for teams that want to intercept Claude Code behavior, add custom logic at defined workflow points, enforce policy, or capture data that is not packaged as a reporting API. This is an engineering control and instrumentation surface, not a turnkey analytics feed. It is best suited to platform teams, security teams, and developer-experience teams that are comfortable owning scripts or services that run in the path of developer workflows. See Anthropic's hooks reference.
What you get
Hooks give you structured access to events inside the Claude Code lifecycle. Anthropic documents event families such as SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Notification, Stop, SubagentStart, SubagentStop, and more. Command hooks receive JSON over stdin, while HTTP hooks receive the same JSON in the POST body. That makes hooks a flexible place to collect event-level context, add organization-specific tagging, or push data to an internal service as work happens. See Anthropic's hooks reference.
One detail is especially useful here: the SessionStart payload includes the transcript_path, current working directory, model, and session source such as startup, resume, clear, or compact. That gives you a bridge between runtime events and the local transcript files on disk, which is extremely useful if you want to correlate orchestration events with the underlying session record. See Anthropic's hooks reference.
Start date of data
Hooks are a forward-only source. Once configured, they can capture events going forward. They do not backfill historical Claude Code activity. If historical reconstruction is needed, the session files or an external store that already captured them will be required. See Anthropic's hooks reference.
Freshness
Hooks execute at lifecycle points while Claude Code is running. This is as close as you get to in-process instrumentation without building directly into the product. That makes them appropriate for enforcement, notification, enrichment, or streaming data out to your own service. It does not automatically make them a good management reporting source, because the emitted data still needs to be normalized, persisted, and analyzed.
How to connect
Hooks are connected by writing either command hooks or HTTP hooks and registering them in Claude Code. Anthropic's docs are explicit that command hooks receive JSON via stdin and communicate through exit codes, stdout, and stderr, while HTTP hooks receive the JSON payload in the POST body and communicate through the HTTP response body. In practice, the real design choice is whether lightweight local scripts are sufficient or a more centrally managed service endpoint is the better fit. See Anthropic's hooks reference.
Important limitations
Hooks are powerful, but they are also ongoing work. Anthropic gives you the event lifecycle and the payload structure. You still own reliability, centralization, schema evolution, error handling, and whatever downstream storage or reporting is required. The value is flexibility. The cost is engineering ownership.
There is another practical limitation: hooks are not a complete substitute for session data. They tell you that something happened at a lifecycle point and can carry rich context, but they do not replace the full local transcript when exact message-by-message reconstruction is required. Hooks are excellent for control and event capture, but they are not the same thing as a full conversation archive.
Project session data
Who this is for
The project session files are for teams that need the fullest local fidelity of what happened inside a Claude Code session: prompts, tool use, results, and the surrounding sequence of activity. This is the most direct source if the priority is forensic reconstruction, deep internal analysis, or building a custom data product from Claude Code's own local record. It is not the best source if the goal is a leadership dashboard with minimal operational overhead. See Anthropic's How Claude Code works, Work with sessions, and Persist sessions to external storage.
What you get
Anthropic says Claude Code saves the conversation locally as you work, and each message, tool use, and result is written to a plaintext JSONL file under ~/.claude/projects/. For local analysis, this is the richest source in the product. It gives you the raw session-level record rather than an aggregated summary. If you need to understand exactly what happened in a session, this is where the truth lives first. See Anthropic's How Claude Code works.
The important nuance is that this is complete local fidelity, not automatically complete organizational fidelity. Anthropic's session-store docs make clear that the default behavior is local-disk persistence, and cross-host durability requires a SessionStore adapter that mirrors those transcripts to your own backend such as S3, Redis, or a database. See Anthropic's Persist sessions to external storage.
Start date of data
This is the one source that can genuinely include historical detail for sessions that already exist on disk. Anthropic writes the session transcript locally by default, so if the files are present, there are historical local records. The catch is that this is only as complete as the workstation or runtime environment you still control. It is not guaranteed organization-wide unless you deliberately centralize it. See Anthropic's How Claude Code works and Persist sessions to external storage.
Freshness
Freshness depends on how the data is accessed. Locally, the data is written as the session runs, so the source itself is current on that machine. If you are relying on mirrored storage, Anthropic says the mirror is a best-effort secondary write: Claude Code writes to local disk first, then the SDK forwards batches to the external store. If the append to the store fails, the local transcript remains durable, but the mirrored store can fall behind or miss batches. In practice, "immediate" is true locally and only conditionally true in any centralized copy. See Anthropic's Persist sessions to external storage.
How to connect
At the simplest level, connection means reading the JSONL session files under ~/.claude/projects/. If cross-host access or centralized analysis is needed, Anthropic provides a SessionStore adapter model that mirrors transcripts to external storage. Anthropic explicitly describes this as a mirror, not a replacement: the subprocess always writes to local disk first, then the SDK forwards each batch to append(). See Anthropic's Work with sessions and Persist sessions to external storage.
Important limitations
The first limitation is governance. Anthropic documents these transcripts as plaintext JSONL files on disk. That makes them powerful, but it also means retention, access control, encryption, and legal review need to be handled deliberately before this is treated as a default reporting source. See Anthropic's How Claude Code works and Persist sessions to external storage.
The second limitation is that centralization is neither automatic nor lossless by default. Anthropic's session-store documentation says mirror writes are best-effort, failed mirrored batches are not retried automatically, and retention in your external store is your responsibility. It also notes that getSessionMessages returns the post-compaction chain, not necessarily the full raw history, which means the safest way to preserve exact raw history is to ingest the raw files or raw store data rather than rely only on a higher-level resume view. See Anthropic's Persist sessions to external storage.
A final operational detail is easy to miss until it becomes a problem. Anthropic notes that if session resume does not find the expected history, a common cause is a mismatched working directory, because sessions are stored under ~/.claude/projects/<encoded-cwd>/*.jsonl. The path structure itself becomes part of the lookup model. That is not a problem if you are reading raw files intentionally. It is a real problem if you assume resume semantics will behave like a globally addressable session service. See Anthropic's Work with sessions.
Why minware, rather than building your own integration
The sources covered in this guide are well-documented and technically accessible. An experienced engineer can start pulling data from the Claude Code Analytics API in an afternoon. That accessibility is part of what makes the build-your-own path feel reasonable at first.
The harder question is what comes after the first pull.
Most internal Claude Code reporting projects follow a predictable arc. A script gets written to hit one endpoint. It works. Someone asks for a second source. A second script gets written. Then someone asks for the data to appear next to sprint velocity or PR cycle time, and the scripts quietly become a pipeline, which quietly becomes something that needs to be maintained, monitored, and documented. By the time the project is a dependency, it is often owned by whoever happened to build it, not by the team that needs the answer.
minware is designed to short-circuit that arc. The AI Tool Contributions dashboard already maps to the questions this guide has been working through - adoption by user and team, output signals like commits and lines changed, token usage, and estimated cost - without requiring you to define the schema, build the normalization layer, or wire up the reporting model yourself. The Claude Code Analytics API data arrives in a shape minware already knows how to work with.
There are four practical reasons this matters more than the initial build cost suggests.
You get correlated context, not isolated metrics. The value of Claude Code data is not just how much Claude Code is being used. It is whether usage is moving the numbers that already matter: cycle time, PR throughput, review lag, quality, deploy frequency. minware holds your Git, Jira, GitHub, and CI data alongside your Claude Code data, and minQL lets you query across all of it. That cross-source correlation is the part that is genuinely difficult to build yourself, because it requires not just ingestion but a consistent identity model, a shared time axis, and enough schema discipline to survive team turnover.
The data model stays maintained. Anthropic's APIs are evolving. The Claude Code Analytics API, the Enterprise Analytics API, and the session-store model are all relatively recent additions to the product surface, and the field schemas, freshness characteristics, and access requirements documented in this guide will change over time. When that happens, minware absorbs the update. A homegrown pipeline absorbs it the next time someone notices the numbers look wrong.
Governance is already handled. Access control, audit trails, and retention policies are not optional when Claude Code data includes token usage, cost attribution, and user-level activity records. In a DIY model, those are your problems to solve. In minware, they are part of the platform.
The minware MCP Server means Claude Code can query its own data. Once your Claude Code metrics are in minware, the minware MCP Server lets Claude Code itself query your engineering analytics through minQL. That closes a loop that a homegrown pipeline cannot easily replicate: the same tool generating the usage data becomes capable of reasoning about it.
For most engineering leadership teams, the goal is visibility, not infrastructure. minware exists at that layer. The question worth asking first is whether the reporting problem actually requires building your own solution.
Conclusion
For most engineering leadership teams, the right answer is not to pick one Claude Code data source and force every question through it. Choose each source for what it is actually good at.
If your priority is executive reporting on adoption, productivity signals, and estimated cost by user, start with the Claude Code Analytics API. If your priority is broader Anthropic API usage and spend, use the Usage and Cost API. If you are an Enterprise customer focused on engagement and adoption reporting across Claude and Claude Code, the Analytics API is the more direct fit. If you need near-real-time observability, use OpenTelemetry. If you need control points and custom instrumentation, use hooks. If you need the most complete local record of what happened in a session, work from the session files and session-store model.
The data is available. The harder problem is turning it into something leadership can act on - answers that sit next to your cycle time, your PR throughput, and the rest of your delivery picture rather than in a separate spreadsheet someone updates manually.
That is what minware is built for. The minware surfaces Claude Code adoption, output, and cost data alongside your existing engineering metrics, without requiring a custom pipeline to get there.
Claude Code gives you multiple paths to the data. minware gives you somewhere useful to land it.