Follow Discord
Sweep 06 Nov 2026 · 01:32Z Build v2.1.319 537 read Stable v2.1.311 Latest v2.1.319 Next v2.1.319 Feeds RSS JSON llms.txt llms-full.txt Unofficial
HomeDocsClaude Developer Platform 5 Nov 2026
One change · api

analytics-api changedmanage-claude/analytics-api

Nearest release: v2.1.319, published an hour after this site recorded the change. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.

Recorded here
Lines+5added
Lines−5removed
From line 85 where the diff opens
First seen 14 Aug 2026 this site's first read of the page
Recorded edits19to this page, all time

The whole hunk

from line 85, old and new numbered
/
lines
from line 85
8585 
8686Claude Enterprise Analytics API data is available for dates on or after January 1, 2026.
8787 
88**Engagement and adoption endpoints** (user activity, summaries, projects, skills, connectors) return a per-day snapshot for the date you specify. Data for a given day is typically available by about 13:00–13:30 UTC the following day (a 1-day lag); until then, the most recent available day is usually 2 days before the current UTC date. Data arrives later on days when an upstream data pipeline runs late, and exact freshness varies by query, so rather than assuming a fixed time, check the error response: requesting a date that is not yet available returns a 400 error naming the most recent available day. If data is not available well past the typical lag, it usually indicates a data pipeline failure on Anthropic’s side; contact support if the gap persists.
88**Engagement and adoption endpoints** (user activity, summaries, projects, skills, connectors) return a per-day snapshot for the date you specify. Data for a given day is typically available by about 13:00–13:30 UTC the following day (a 1-day lag). Until then, the most recent available day is usually 2 days before the current UTC date. Data arrives later on days when an upstream data pipeline runs late, and exact freshness varies by query. Rather than assuming a fixed time, check the error response: requesting a date that is not yet available returns a 400 error naming the most recent available day. If data is not available well past the typical lag, it usually indicates a data pipeline failure on Anthropic’s side; contact support if the gap persists.
8989 
9090**Cost and usage endpoints** follow a different freshness model. Data is typically available within 4 hours of the underlying usage but might take up to 24 hours. Values can be revised as late events arrive and reconciliation runs, until about 7 days after the end of the calendar month. For example, values for October 1 can change until about November 7. For invoicing-grade totals, query only months that ended at least 7 days ago.
9191 
9292<Note>
93 Cost and usage responses include a `data_refreshed_at` timestamp. When `ending_at` is omitted (the default is the current time), the response includes a tail of data after `data_refreshed_at` that is incomplete. For stable results across repeated calls, set `ending_at` to a value at or before a previously returned `data_refreshed_at`.
93 Cost and usage responses include a `data_refreshed_at` timestamp. If you omit `ending_at`, it defaults to 31 days after `starting_at` or the current time, whichever is earlier. That range can run past `data_refreshed_at`, and data after that time is incomplete. For stable results across repeated calls, set `ending_at` to a value at or before a previously returned `data_refreshed_at`.
9494</Note>
9595 
9696## How metrics are defined
from line 105
105105 
106106In user activity and in skill, connector, and plugin usage, this usage appears in the `chat_cowork_unified_metrics` object. In activity summaries, it is counted in `chat_cowork_unified_daily_active_user_count`, `chat_cowork_unified_weekly_active_user_count`, and `chat_cowork_unified_monthly_active_user_count`.
107107 
108As more users start using Chat and Cowork unified, usage moves out of your chat and Cowork figures and into these new ones. Usage from days before a user starts using Chat and Cowork unified stays under chat or Cowork. Organization-wide figures, such as total token usage, total cost, and overall active user counts, do not change. Cost and usage reports filtered by product leave Chat and Cowork unified usage out unless `products[]` includes `chat_cowork_unified`.
108When a user starts using Chat and Cowork unified, their usage moves out of your chat and Cowork figures and into the Chat and Cowork unified figures. Usage from days before a user starts using Chat and Cowork unified stays under chat or Cowork. Organization-wide figures, such as total token usage, total cost, and overall active user counts, do not change. Cost and usage reports filtered by product leave Chat and Cowork unified usage out unless `products[]` includes `chat_cowork_unified`.
109109 
110110Some activity from users of Chat and Cowork unified, such as voice mode, can still be reported under chat or Cowork. A user’s activity can also be split between products on the day they start using Chat and Cowork unified. The same is true on the day it is turned off for them. How the activity splits is not guaranteed.
111111 
from line 113
113113 
114114When you filter user activity by project, each day’s project activity is counted in one place only. If a user sent a chat message in Chat and Cowork unified that day, all their project activity is counted in `chat_cowork_unified_metrics.chat`. Otherwise, it is counted in `chat_metrics`.
115115 
116**Per-product metric blocks.** Per-product metric objects (for example, Office Agent or Cowork metrics on a user-activity record) are always present on every record. Organizations without usage of that product see all-zero values rather than `null`. The exception is Chat and Cowork unified: on deployments that do not offer it, its fields are left out of the response.
116**Per-product metric blocks.** Per-product metric objects (for example, Office Agent or Cowork metrics on a user-activity record) are always present on every record. Organizations without usage of that product see zero counts rather than a `null` object. The exception is Chat and Cowork unified: on deployments that do not offer it, its fields are left out of the response. Individual fields inside these objects can be `null`, which means the value is not available. For example, when you filter user activity by project, `distinct_skills_used_count` in `chat_metrics` is `null`. The [Claude Enterprise Analytics API reference](https://platform.claude.com/docs/en/api/beta/organization/analytics) shows which fields can be `null`.
117117 
118118**Connector names.** Connector names are normalized across sources. For example, `Atlassian MCP server`, `mcp-atlassian`, and `atlassian_MCP` all appear as `atlassian` in the connector usage endpoint.
119119 
from line 129
129129 
130130## Versioning
131131 
132Send the `anthropic-version` header on every request; see [API versions](https://platform.claude.com/docs/en/api/versioning) for the available versions.
132Send the `anthropic-version` header on every request; see [Versions](https://platform.claude.com/docs/en/api/versioning) for the available versions.
133133 
134134## Known limitations
135135 
Feedback