What the Claude Compliance API actually shows you

If you run Claude Enterprise and someone has asked you to prove what your team is doing with it, the Compliance API is where you start. It is genuinely good, it is properly documented, and it answers a narrower question than most people assume when they first hear the name.

This is what it gives you, what it does not, and what you can build from the difference.

The three things it covers

The Compliance API divides into three areas. Keeping them separate in your head saves a lot of confusion later, because they have different scopes and different access requirements.

The activity feed. GET /v1/compliance/activities returns per-event records: a chat was created, a file was uploaded, a setting was changed, someone signed in. This is the audit log.

The directory. Endpoints listing organisations, users, roles, groups and the effective settings in force for each organisation. This is who exists, what they can do, and how the tenant is configured.

The content. Endpoints to retrieve, and delete, the underlying chats, files, projects and project attachments.

Everything sits under /v1/compliance/* on api.anthropic.com and authenticates with an x-api-key header. All of it shares one rate limit of 600 requests per minute per parent organisation, which matters when you design a polling loop.

What an activity record actually contains

Worth looking at a real one, because the shape tells you what the feed is for:

{
  "id": "activity_01XyDMpzjS89pFZXqSFUBDr6",
  "created_at": "2026-04-10T08:09:10Z",
  "organization_id": "org_01Wv6QeBcDfGhJkLmNpQrSt8",
  "actor": {
    "type": "user_actor",
    "email_address": "user@example.com",
    "user_id": "user_01TuVwXyZaBcDeFgH2JkLmN4",
    "ip_address": "192.0.2.34",
    "user_agent": "Mozilla/5.0..."
  },
  "type": "claude_chat_created",
  "claude_chat_id": "claude_chat_01XyDMpzjS89pFZXqSFUBDr6",
  "claude_project_id": "claude_proj_01KGp4eZNug9ri4kE35RSppq"
}

That is a resource lifecycle event. Who did a thing, to what, when, from which address, using which client.

It is not a record of what the model did. There is no prompt here, no model name, no tool invocation, no tool response. The feed tells you a chat came into existence. Reading what was in it is a separate call to a separate endpoint with a different key.

That distinction is the single most useful thing to understand about this API, and it is the source of most disappointment when teams first wire it up expecting a transcript of AI behaviour.

The two keys are not interchangeable

A practical trap worth knowing before you provision anything.

Teams frequently start with an Admin API key because that is the one their platform team already has, get the activity feed working, and then discover the content endpoints are closed to them. The feature also has to be enabled for your organisation by your account team before any of it works.

Coverage is uneven across surfaces

This is the part that most affects what you can actually claim.

A Claude Enterprise tenant has a parent organisation with linked organisations underneath it, of two kinds: claude.ai organisations, where people chat and store content, and Claude Console organisations, where teams run API workloads.

The directory endpoints span both. The content endpoints serve claude.ai data only.

So the coverage you get depends on where the work happens:

That last row is not a limitation of the API. It is definitional. The Compliance API reports on your organisation's tenant, and an employee's personal account is not in it. If someone pastes a client document into a personal chatbot on a work laptop, nothing in this API will ever tell you.

What it does not show

Being precise here matters, because this is where teams over-claim to auditors.

Inference detail. The activity feed records resource lifecycle, not what ran. No prompts, no model selection, no reasoning. If your control claims "we monitor what staff ask AI", the feed alone does not evidence that; the content endpoints do, and only for claude.ai.

Tool calls and MCP traffic. Which tool an agent invoked, with what arguments, and what came back is not exposed. This is the gap that matters most as teams move from chatting to agents doing work, because the tool call is the moment something real happens to a real system. Independent analysis of the API's coverage reaches the same conclusion, noting there is no record of MCP server traffic and that Claude Code inference prompts and tool decisions are absent.

Skill contents. What is packed inside a Skill, including any scripts it carries, is not surfaced. Given that Anthropic's own guidance warns a Skill can direct a model to invoke tools in ways that do not match its stated purpose, that is a meaningful blind spot for anyone reviewing what their team is running.

Anything outside Enterprise. The API is an Enterprise feature. It has no view of Team plans, personal accounts, or other vendors' tools entirely.

What you can genuinely build with it

Plenty, as long as the claims match the coverage.

1. A real SIEM feed. Poll the activity feed, normalise the records, and correlate Claude events with the rest of your estate by user and IP. Actor records carry email, user ID, IP and user agent, which is enough to join against identity and network data.
2. Joiner, mover, leaver assurance. The directory endpoints let you reconcile Claude membership, roles and groups against your HR source of truth, and evidence it on a schedule rather than by screenshot.
3. Configuration drift detection. Effective settings per organisation are retrievable, so you can snapshot them and alert when something changes rather than finding out at the next audit.
4. eDiscovery and deletion on request. Content endpoints support both retrieval and deletion, which is what a subject access request or a legal hold actually requires.
5. Content inspection against a watch list. Because chats, files and projects are retrievable for claude.ai, you can check what is going in against the names, matters or clients you care about.

Two things to design in early. The activity feed is retained for six years by Anthropic, whereas content retention follows your organisation's own policy, and hard-deleted data is not retained at all. So the event that a chat existed may outlive the chat itself. Plan your own retention accordingly, rather than assuming the API is your archive.

Compliance API or the other options

Worth ruling out the adjacent features quickly, because they get confused.

The CSV export is fine for a one-off. For anything ongoing, standardise on the Compliance API. The Analytics APIs answer a genuinely different question and are provisioned separately, so do not expect one to substitute for the other.

The honest summary

The Compliance API is the right foundation and it is better than what most AI vendors offer. It gives you a durable, six-year event trail, a directory you can reconcile, and retrievable content for the surface where most chatting happens.

What it does not give you is the layer where agents act. Tool calls, MCP traffic, what a Skill contains, and anything happening on a personal account or a laptop. Those are precisely the places where an AI system stops being a conversation and starts touching real systems, which is also where the risk moved when teams started using AI to do work rather than answer questions.

That is the gap Connor is built around: cover the surfaces the vendor APIs reach, and cover the ones they do not, so the record is complete enough to be worth relying on. If you want to see the shape of that gap in your own estate, the shadow AI scan is the fastest way to find out what is already connected.