--- title: Which Claude sessions does the Compliance API actually capture? url: https://deepthinkingai.org/compliance-api-session-coverage-gaps/ published: 2026-09-19 author: Shekhar Singh topic: AI Engineering tags: compliance-api, claude-enterprise, data-retention, ediscovery, dlp site: DeepThinking AI --- # Which Claude sessions does the Compliance API actually capture? **Summary:** Anthropic's Compliance API added beta coverage of Claude in Chrome sessions on 18 September 2026, but its own docs show it never captures sessions under zero data retention or HIPAA readiness, Claude Code run through a Console key or Bedrock, or cloud Claude Code sessions, and a naive polling loop can permanently drop a session still being written. ## Key takeaways - Anthropic added beta coverage of Claude in Chrome sessions to the Compliance API on 18 September 2026. - The Compliance API captures no local sessions from organizations with HIPAA readiness enabled, none at all. - Local sessions run through a Claude Console API key, Bedrock, Google Cloud or Microsoft Foundry never reach the Compliance API. - A polling window set to the exact time of the previous run can permanently drop a session still being written. - The remote session endpoints carry a second, undisclosed rate limit whose 429 always reports a one second retry-after. Anthropic added Claude in Chrome to the Compliance API's session coverage on 18 September 2026, extending a table that already listed Cowork, Claude Code, Claude Science and Claude for Microsoft 365. Read on its own, that looks like coverage converging on complete. Read the rest of the documentation and the exclusions turn out to be wider than the coverage: whole categories of session never reach a compliance reviewer, and a common way of polling for new ones throws sessions away for good. ## Which Claude sessions does the Compliance API actually capture? The Compliance API splits sessions by where they run. Local session endpoints cover apps on a user's machine: Cowork in Claude Desktop, Claude Code in the terminal, Claude Desktop or an IDE extension, the Claude Science desktop app, Claude for Microsoft 365's Excel, PowerPoint, Word and Outlook add-ins, and, as of the [18 September 2026 release](https://platform.claude.com/docs/en/release-notes/overview), the Claude in Chrome browser extension's built-in chat. Remote session endpoints cover the opposite case: Cowork sessions started on claude.ai web or mobile, which run in Anthropic-managed cloud infrastructure rather than on the user's device. Each session carries a `product_surface` value naming which of these created it, from `cowork` to `claude_in_chrome` to `office_agents/excel`. Coverage of Claude Science, Microsoft 365 and Claude in Chrome is still in beta; only Cowork and Claude Code sessions are marked stable in [Anthropic's documentation](https://platform.claude.com/docs/en/manage-claude/compliance-sessions). ## Which sessions never reach the Compliance API at all? Two exclusions are absolute rather than partial. The [documentation](https://platform.claude.com/docs/en/manage-claude/api-and-data-retention) states plainly that the Compliance API does not capture local sessions for which zero data retention is in effect, or any local sessions from organizations with HIPAA readiness enabled. That exclusion covers every session in those organizations. It is not limited to the sessions that happen to touch protected health information. A third gap sits in how Claude Code authenticates: only sessions signed in with a Claude Enterprise account reach these endpoints, so Claude Code run with a Claude Console API key, or through Amazon Bedrock, Google Cloud or Microsoft Foundry, is invisible to a compliance reviewer relying on this API. A fourth gap is about naming rather than policy. Claude Code cloud sessions run on Anthropic's cloud infrastructure instead of a user's laptop, but they are explicitly not remote sessions in this API's sense. The remote session endpoints return Cowork sessions only, so a security team auditing "everything that ran in the cloud" will miss an entire product by trusting the label. ## How does the local session polling window silently drop sessions? An integration that wants to catch newly active sessions polls the list endpoint with `updated_at.gte` set to the time of its previous run. The [documentation](https://platform.claude.com/docs/en/manage-claude/compliance-sessions#retrieve-local-sessions) describes exactly where that goes wrong: `updated_at` on the list endpoint is a lower bound, and for a session still active at a window boundary it can momentarily lag behind the session's true last activity, because a new call only becomes queryable after a short indexing delay. A bound set to the exact previous run's start time silently and permanently drops a session whose final call was still indexing at that moment, because once the bound advances past that call, no later run returns it. The fix is to set each run's `updated_at.gte` a few minutes earlier than the previous run's start time rather than at that exact timestamp, and to run a periodic reconciliation pass over older windows as a backstop. **How a fixed polling bound permanently drops a session** ```mermaid sequenceDiagram participant Exportjob as Export job participant ComplianceAPI as Compliance API Exportjob->>ComplianceAPI: list, updated_at.gte = T0 ComplianceAPI-->>Exportjob: Sessions active up to that instant Exportjob->>Exportjob: Next run sets updated_at.gte to T0 again Exportjob->>ComplianceAPI: list, updated_at.gte = T0 ComplianceAPI-->>Exportjob: That session never appears again ``` - list, updated_at.gte = T0: T0 is the previous run's exact start time. - Sessions active up to that instant: One call finishing right at T0 is still indexing. - Next run sets updated_at.gte to T0 again: The still-indexing call is now before the bound. - That session never appears again: No later window's lower bound reaches it. Setting the next poll's lower bound to the exact instant the previous one started, instead of a few minutes earlier, permanently excludes a session whose last call was still being indexed at that moment. Source: platform.claude.com/docs/en/manage-claude/compliance-sessions ## What does a captured session transcript actually include? Even a session inside every included category is not returned in full. Thinking blocks are never included, in local or remote transcripts alike. The request's system prompt is never returned either; a marker message reading "[system prompt content not shown]" stands in for it once per session. Images, PDFs and other binary or structured blocks come back as a placeholder such as "[image content not shown]", and citation metadata on a web-search-grounded answer is stripped from a text block that otherwise reads normally, with `truncated` set to true as the only sign anything is missing. Tool inputs and tool result text are capped at 10,000 bytes each by default, rising to about 1 MiB per string on request, and a `tool_use` input cut off at that boundary is no longer valid JSON, so parsing it without checking the `truncated` flag first will throw on exactly the sessions with the largest, and often most interesting, tool calls. **What a local session transcript includes and omits** 1. User prompts and assistant text Sent as is, only size-truncated 2. Tool calls and tool result text 10,000 bytes each by default --- System prompt --- (Replaced by one marker message) 3. Thinking, images, PDFs, citations Never returned, placeholder only A session inside every covered product still loses its thinking, its system prompt and any binary content. Only size limits touch prompts, replies and tool traffic. Source: platform.claude.com/docs/en/manage-claude/compliance-sessions ## What happens to a session's transcript after Claude compacts its context? Session transcripts intersect with [Claude's compaction features](/claude-compaction-modes/) in a way neither document mentions the other. When a client rewrites or compacts its conversation history mid-session, the Compliance API inserts a `synthetic_marker` record at that point and continues the transcript with whatever the client sent afterward. For an organization with a finite custom retention period, a second marker withholds the rewritten history entirely, so only the latest user turn and what follows it are shown. Nothing here is a deletion in the retention sense: the underlying calls are still subject to the same six year or custom retention window as everything else. It reads as one to a reviewer who does not know to look for the marker type, because a `synthetic_marker` record and a genuinely empty turn look identical unless the code checks `provenance.type` before rendering. ## How many Compliance API requests can you make before you get rate limited? The Compliance API allows [600 requests per minute per parent organization](https://platform.claude.com/docs/en/manage-claude/compliance-errors#429-too-many-requests), one budget shared across every Compliance Access Key and Admin API key under that parent and across every `/v1/compliance/*` endpoint, rather than a separate budget per key or per endpoint. The remote session endpoints carry a second request budget on top of that shared limit, and its 429 response always reports a `retry-after` of 1 second, described in the documentation as a minimum wait rather than the actual reset time, so a client that treats that value as authoritative will hammer the same limit repeatedly. A related trap sits in the 404s: "Local sessions are not available" means the endpoints are temporarily unavailable to your whole organization and can clear on its own, while "Local session not found" means one specific session is gone or unreadable. Both share the `not_found_error` type, similar to how [Claude's auto permission policy](/auto-permission-policy-intent-channel/) also collapses distinct outcomes under one field, so code that branches on type instead of message text will treat a transient outage as a permanently missing session. ## Should you rely on the Compliance API as your only session record? No, not if any part of your organization touches the categories it excludes. The Compliance API's own documentation offers the honest comparison: OpenTelemetry logging is push rather than pull, captures host and device metadata the Compliance API never returns, and is the only option for Claude Code sessions run through a Console API key or a third-party cloud platform. A team that needs a defensible record for eDiscovery or DLP across an organization with any HIPAA-ready or ZDR-enabled users, any non-Enterprise Claude Code usage, or any Claude Code cloud sessions cannot get that record from the Compliance API alone, whatever the word "compliance" in its name implies. The API is still the right default for what it does cover: it needs no collector, works with a key most Enterprise organizations already hold, and the transcript format is stable enough to build a real export pipeline around. Pair it with OpenTelemetry logging for the sessions it structurally cannot see, rather than assuming Chrome coverage closed every gap. ## What does the documentation still leave unanswered? Two things are not stated anywhere in the Compliance API docs. The size of the remote session endpoints' second rate limit budget is never given a number, only that it exists and that its 429 caps `retry-after` at one second regardless of how much of the budget is actually left, so a client cannot budget against it the way it can budget against the disclosed 600-per-minute shared limit using the `anthropic-ratelimit-requests-remaining` header. And the documentation does not say through which endpoint, if any, a Claude Code cloud session becomes visible, only that it is excluded from both session endpoint families by definition. Anthropic's own comparison table names Claude Code cloud sessions as a case the remote endpoints do not cover, without naming what does. Until that is answered publicly, treat any Claude Code cloud usage in a Claude Enterprise organization as unaudited by this API, and confirm the gap directly with Anthropic before representing coverage to a customer or a regulator. ## Build a Compliance API export that doesn't quietly lose sessions Most of the ways this API loses data are silent. Nothing errors, a response just leaves out what a reviewer expects, so the check has to be built in rather than triggered by a failure. 1. **Rule out sessions the API will never return**: Confirm whether any organization you export from has HIPAA readiness enabled or ZDR set for some users, since both exclude local sessions completely, and check whether any Claude Code usage runs through a Console API key, Bedrock, Google Cloud or Microsoft Foundry, none of which reach these endpoints. 2. **Use the endpoint family that matches where the session ran**: Local session endpoints cover Cowork, Claude Code, Claude Science, Claude for Microsoft 365 and Claude in Chrome on a user's machine. Remote session endpoints cover only Cowork started on claude.ai web or mobile; a Claude Code cloud session is neither. 3. **Poll with a bound set before your previous run's start time**: Set updated_at.gte a few minutes earlier than when your previous run started. Do not set it to that exact timestamp, because a bound at the exact previous time can permanently skip a session whose last call was still indexing at that moment. 4. **Deduplicate incoming sessions and messages on their id**: created_at can advance as older calls in a session age past retention, so re-walking the same window can show a session with a different created_at than before. Track identity by id instead. 5. **Treat provenance flags as present but unverified**: content_unavailable, client_asserted and synthetic_marker each mean something different happened to that turn. Surface them to reviewers rather than rendering an empty message as though nothing was ever there. 6. **Budget requests under 600 per minute per parent organization**: That limit is shared across every key and every /v1/compliance/* call. Watch the anthropic-ratelimit-requests-remaining header, and back off exponentially on the remote session endpoints' separate budget, since its 429 always reports a one second retry-after regardless of the real reset time. 7. **Run a full reconciliation pass on a regular schedule**: Do this in addition to incremental polling. Retrieving a session or its messages directly always reflects the latest retained call, so a periodic sweep over an older window catches whatever an incremental poll's lag or an expired 24-hour cursor missed. ## Frequently asked questions ### Does the Compliance API capture Claude Code sessions run through Amazon Bedrock or Google Cloud? No. The session endpoints only capture Claude Code signed in with a Claude Enterprise account against Anthropic's own API. Sessions authenticated with a Claude Console API key, or run through Bedrock, Google Cloud, or Microsoft Foundry, are excluded entirely. ### Does enabling HIPAA readiness change what the Compliance API sees? Yes, completely. The documentation states plainly that the Compliance API does not capture any local sessions from organizations with HIPAA readiness enabled, not only the sessions that happen to touch protected health information. ### Are Claude Code cloud sessions the same as remote sessions? No, and the naming invites that mistake. Claude Code cloud sessions run in Anthropic's cloud but are not remote sessions in this API's sense; the remote session endpoints return Cowork sessions only. ### How often can I poll the Compliance API's session endpoints? Up to 600 requests per minute per parent organization, shared across every key and every /v1/compliance/* endpoint. The remote session endpoints carry a second budget on top of undisclosed size, whose 429 always reports a one second retry-after regardless of the real reset time. ### Does compaction delete anything from a session's compliance record? Not in the retention sense. Mid-session compaction inserts a synthetic_marker where the client rewrote its history, and organizations with a finite retention period get a second marker withholding that rewritten history, so a reviewer sees a gap rather than deleted content. ## Sources - [Retrieve session transcripts](https://platform.claude.com/docs/en/manage-claude/compliance-sessions). Anthropic - [Claude API release notes](https://platform.claude.com/docs/en/release-notes/overview). Anthropic, 2026-09-18 - [Handle Compliance API errors](https://platform.claude.com/docs/en/manage-claude/compliance-errors). Anthropic - [API and data retention](https://platform.claude.com/docs/en/manage-claude/api-and-data-retention). Anthropic --- Canonical HTML: https://deepthinkingai.org/compliance-api-session-coverage-gaps/