Claude API Audit Logs: Compliance Tracking Guide

Claude API audit logs and compliance tracking: the short answer

The Claude API itself does not ship a built-in audit log dashboard. If you need to prove who called the model, when, with what data, and what came back, you have to build that layer yourself — or use a proxy/gateway that logs requests on your behalf. For most teams working toward SOC 2, ISO 27001, GDPR, or internal security review, "compliance tracking" means three things: request-level logging (who, what, when), data retention with defined deletion windows, and access attribution (which team member or service account made the call).

This matters because the Claude API is stateless by design — Anthropic doesn't store your conversation history for you to query later, and the API response doesn't include an audit trail you can hand to an auditor. If a security reviewer asks "show me every call that touched customer PII in the last 90 days," you need your own system answering that question, not the model provider's.

What "audit log" actually means for an LLM API

A useful audit log for Claude API usage typically captures:

• Request identity: which user, API key, or service account made the call
• Timestamp and latency
• Model and version used (e.g. claude-sonnet vs claude-opus, and the version string)
• Token counts for input and output
• Request metadata: endpoint, whether tools were invoked, whether streaming was used
• Outcome: success, error code, or truncation
• Optionally, the payload itself — though many teams deliberately avoid storing raw prompts/completions to limit PII exposure, logging hashes or redacted summaries instead

Note what's not usually required: a full transcript archive for every call. Most compliance frameworks care about traceability and access control more than content retention. Decide early whether your audit log stores content or just metadata — that decision drives your retention policy and your data classification.

Why native API usage is hard to audit

If you're calling the Claude API directly with a single shared key across a team, you lose per-user attribution immediately. Everyone looks like "the API key." That's the first problem auditors flag: shared credentials with no individual accountability. The fix is either:

1. Issue separate API keys per user/service and track usage per key, or
2. Put a gateway in front of the API that assigns per-user tokens and logs at the gateway level

Option 2 is usually faster to implement and easier to audit, because the logging logic lives in one place instead of being duplicated across every service that calls the model.

Building a minimal audit log layer

A pragmatic approach: wrap every outbound call in a logging middleware that writes a structured record before and after the request.

async function callModelWithAudit({ userId, requestId, payload }) {
  const startedAt = new Date().toISOString();

  const response = await fetch("https://api.subtoapi.app/v1/messages", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.SUBTOAPI_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify(payload),
  });

  const data = await response.json();

  await auditLog.write({
    requestId,
    userId,
    model: payload.model,
    inputTokens: data.usage?.input_tokens,
    outputTokens: data.usage?.output_tokens,
    status: response.status,
    startedAt,
    finishedAt: new Date().toISOString(),
  });

  return data;
}

Keep this append-only — audit logs that can be edited after the fact aren't audit logs. A simple pattern: write to an immutable store (object storage with versioning, or a database table with no UPDATE/DELETE grants for the application role) and run periodic exports to a separate compliance archive.

Mapping this to real compliance frameworks

• SOC 2 (CC7.2, CC6.1): requires evidence of access controls and monitoring. Per-user API attribution and logged access events satisfy the monitoring piece directly.
• GDPR: if prompts or completions contain personal data, you need a lawful basis, a retention limit, and the ability to delete a specific user's records on request. Design your audit log schema so a single user's rows can be located and purged without touching others.
• HIPAA: if you're processing PHI through the Claude API, you need a signed BAA with the provider you're using and an audit trail showing who accessed what PHI and when — this is non-negotiable for covered entities.
• Internal security review: often just wants proof that access is scoped by role and that there's a record of who used production credentials.

In each case, the actual logging mechanics are similar: capture identity, capture action, capture timestamp, store it somewhere tamper-resistant, and set a retention policy you can defend.

Retention, redaction, and key rotation

Three operational habits make audit logs actually useful instead of just a compliance checkbox:

• Set an explicit retention window (commonly 90 days to 1 year depending on framework) and automate deletion past that window — don't rely on manual cleanup.
• Redact or hash sensitive fields before they hit the log store if you don't have a reason to keep raw content.
• Rotate API keys on a schedule and log key creation/revocation events as part of the same audit trail — a key that's never rotated is a common audit finding.

Where a gateway like SubToAPI fits

If you're already managing a team's access to Claude through SubToAPI, you get per-application API keys (sub_live_...) and usage metadata out of the box, which covers a chunk of the attribution problem without building it from scratch. Each key maps to a specific application or team member, and usage data — token counts, request counts — is visible in the dashboard, which you can export into whatever compliance archive you're already running. Combine that with team seats so each person has their own key, and you've solved the "who made this call" question before writing a single line of logging code. Check the quickstart and the messages docs for how key issuance and request metadata work in practice.

Questions

Does Anthropic provide audit logs for the Claude API directly? No built-in audit log dashboard is provided for raw API usage. You need to log requests yourself or use a gateway/proxy that records per-key or per-user activity on your behalf.

What's the minimum data I need to log for compliance? At minimum: who made the request (user or key identity), when, which model, token counts, and the outcome (success/error). Content logging is optional and should be a deliberate decision, not a default.

How long should I keep Claude API audit logs? It depends on your framework — GDPR and most SOC 2 programs work well with 90 days to 1 year, with automated deletion past that window. Set the policy before you start collecting data, not after.