API and data retention

This page covers the Claude API (api.anthropic.com), Claude Platform on AWS, and Claude in Microsoft Foundry, where Anthropic is the data processor. On Amazon Bedrock and Google Cloud's Agent Platform, the cloud provider is the data processor; refer to those platforms' data retention and compliance documentation for their equivalent controls.

Anthropic offers two data handling arrangements for the Claude API: zero data retention (ZDR) and HIPAA readiness. The feature eligibility table lists which API features each arrangement covers. For Anthropic's standard retention policies outside these arrangements, see the commercial data retention policy and the consumer data retention policy.

How Anthropic approaches data retention

Different APIs and features have different storage needs. Where a feature does not require storage of customer prompts or responses, it may be eligible for ZDR. Where a feature necessarily requires storage, Anthropic designs for the smallest possible retention footprint under the following commitments:

• Retained data is never used for model training without your express permission.
• Only what is technically necessary for the feature to work is retained. Conversation content (your prompts and Claude's outputs) is not retained by default; the exception is Covered Models, which require 30-day retention.
• Retained data is purged on the shortest practical time to live (TTL), and Anthropic aims to give customers control over how long data is retained. What is held, and the retention duration where a specific TTL applies, is documented on each feature's page.

Several retention models sit outside the ZDR and HIPAA arrangements described on this page. Data accessible through the Compliance API follows its own retention model. The Activity Feed retains data for 6 years. Chat, file, and project content from claude.ai follows your organization's retention policy set in claude.ai > Organization settings > Data and privacy, unless a user deletes it sooner. Local session transcripts (from sessions on users' machines, in apps such as Cowork and Claude Code) are stored for 6 years by default, or for your organization's custom conversation retention period when a finite one is set (the same claude.ai setting). Remote session transcripts (Cowork in the cloud) are retained for 6 years, unless a user deletes the session sooner. The Compliance API does not capture local sessions for which ZDR is in effect. For organizations with HIPAA readiness enabled, it captures Cowork and Claude Code local sessions only and stores their transcripts for 30 days.

Zero data retention (ZDR)

Under a ZDR arrangement, Anthropic does not store customer prompts or responses at rest after the API response is returned. To request ZDR for your organization, contact the Anthropic sales team. ZDR is enabled per organization; each new organization requires ZDR to be enabled separately by your account team, and enablement does not automatically extend to other organizations under the same account.

What ZDR covers

• Claude Messages and Token Counting APIs: ZDR applies to these endpoints for eligible features listed in the feature eligibility table. Features that ride on /v1/messages but are marked "No" in the table (such as code execution) are not covered.
• Claude Code with API keys: ZDR applies when Claude Code is used with API keys from a Commercial organization (an organization under Anthropic's Commercial Terms of Service, as distinct from a consumer Claude account). If metrics logging is enabled in Claude Code, productivity data such as usage statistics is exempted from ZDR and may be retained. Claude Code on Claude Enterprise is not covered by this arrangement and has a separate ZDR offering; see What ZDR does not cover.
• Claude Platform on AWS: Claude Platform on AWS follows the same data retention policy as the first-party Claude API. ZDR is available on request; contact your Anthropic account representative to enable it.

What ZDR does not cover

• Claude Console: Any usage in the Claude Console, including playground.
• Claude Managed Agents: Claude Managed Agents is a stateful resource; session transcripts persist until you delete them.
• Claude consumer products: Claude Free, Pro, and Max plans, including when customers on those plans use Claude's web, desktop, or mobile apps or Claude Code.
• Claude Teams and Claude Enterprise product interfaces: These interfaces are not ZDR-eligible. The one exception is Claude Code on Claude Enterprise, which has its own ZDR offering, separate from the ZDR arrangement described on this page. That offering is available only to qualified accounts on Claude Enterprise and requires separate enablement by Anthropic. See the Claude Code ZDR documentation, which applies to Claude Enterprise organizations only.
• Claude for Excel: Not currently ZDR-eligible.
• Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, and Claude Mythos 5: These models require 30-day data retention and are not available under ZDR unless expressly authorized by Anthropic. See Model-specific data retention requirements.
• Third-party integrations: Data processed by third-party websites, tools, or other integrations is not covered, though some may have similar offerings. Review each service's data handling practices.
• Cross-Origin Resource Sharing (CORS): CORS is not supported for organizations with ZDR arrangements. To make API calls from browser-based applications, route requests through a backend proxy server. See the API security guidance for proxy patterns and API-key handling.
• Flagged content and legal holds: See Retention regardless of arrangement.

HIPAA readiness

The Claude API supports HIPAA-ready integrations for organizations that handle protected health information (PHI). With a signed BAA and a HIPAA-enabled organization, you can use supported API features to process PHI while supporting your organization's HIPAA compliance. Eligible organizations can review and execute the BAA and enable HIPAA readiness directly from the Claude Console. HIPAA readiness applies a broader set of privacy and security safeguards than ZDR (encryption, access controls, and audit logging that protect PHI throughout its lifecycle) rather than requiring immediate deletion. If your organization handles PHI, HIPAA readiness is the arrangement to use; you do not also need ZDR. See the feature eligibility table for which features each arrangement covers.

What HIPAA readiness covers

• Claude API: HIPAA readiness applies to the Claude API (api.anthropic.com) for eligible features listed in the feature eligibility table.

What HIPAA readiness does not cover

• Claude consumer products: Claude Free, Pro, and Max plans.
• Claude Console: Usage through the Claude Console interface (enabling HIPAA readiness from Console settings is supported; processing PHI through the Console is not covered).
• Partner-operated platforms: Amazon Bedrock and Google Cloud's Agent Platform. Refer to those platforms' compliance documentation.
• Claude Platform on AWS and Microsoft Foundry: HIPAA readiness is not available on these platforms.
• Third-party integrations: Data processed by external tools or services connected to your application.
• Claude Code: Claude Code is not covered under HIPAA readiness.
• Beta features: Features in beta are generally not covered under the BAA unless explicitly listed as eligible in the feature eligibility table.
• Flagged content and legal holds: See Retention regardless of arrangement.

PHI handling guidelines

Protected health information (PHI) includes any individually identifiable health information. In the context of the Claude API, PHI typically appears in message content (prompts and Claude's responses), attached files (images, PDFs), and file names or metadata associated with message content. The following fields are not expected to contain PHI under the BAA: workspace names, user information (name, email, phone number), billing data, and support tickets.

When using structured outputs or tools with strict: true, the API compiles JSON schemas into grammars that are cached separately from message content. These cached schemas do not receive the same PHI protections as prompts and responses. Do not include PHI in JSON schema definitions. This restriction applies to schema property names, enum values, const values, and pattern regular expressions. Patient-specific information should appear only in message content, where it is protected under HIPAA safeguards.

HIPAA error handling

Your signed BAA is the official source of truth for which features are covered. The API also enforces these restrictions automatically. When a HIPAA-enabled organization sends a request that includes a non-eligible feature, the API returns a 400 error to prevent accidental use of features not covered by your BAA:

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "The requested features are not available for HIPAA-regulated organizations without Zero Data Retention: code_execution."
  }
}

The error message lists the non-eligible features detected in the request; remove them and retry. The phrase "without Zero Data Retention" is the API's own wording and does not change the resolution. Client-side tools whose Details column in the feature eligibility table says they are not blocked are accepted but remain outside HIPAA readiness.

Getting started with HIPAA readiness

There are two ways to set up HIPAA-ready API access. Most organizations can enable it directly in the Claude Console with Anthropic's standard BAA; organizations that require a negotiated BAA should work with their account team.

Enable in the Console (standard BAA)

1. 1

   Open your organization's data retention settings

   In Claude Console > Settings > Data retention, organization admins with the HIPAA management permission see a HIPAA compliance card. If your organization is eligible but you don't see the option to enable, ask an organization admin to complete these steps.

2. 2

   Review and execute the BAA

   Download the Business Associate Agreement and the HIPAA Implementation Guide, then accept the agreement as an authorized legal representative of your organization. Each step becomes available after you download the prior document, and your enablement is bound to the exact BAA version you downloaded.

3. 3

   Enablement takes effect immediately

   HIPAA readiness controls are applied to your organization as soon as you accept. Once HIPAA readiness is enabled for your organization, the configuration is permanent and cannot be disabled by an administrator. The API automatically enforces feature restrictions, returning an error for requests that use non-eligible features. See HIPAA error handling for the error and the client-side tool exception.

Contact sales (custom BAA)

If your organization requires a negotiated or custom BAA, or if self-serve enablement isn't available for your organization, contact the Anthropic sales team. Anthropic will execute the BAA and enable HIPAA readiness for your organization.

Build with eligible features

Whichever path you use, confirm which features are supported in the feature eligibility table and review the PHI handling guidelines for features that restrict where PHI can appear. For detailed configuration and compliance requirements, refer to the HIPAA Implementation Guide.

Model-specific data retention requirements

Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, and Claude Mythos 5 are designated Covered Models (see the Covered Models support article) and require 30-day data retention; ZDR is therefore not available for any of them unless expressly authorized by Anthropic. On the Claude API, requests to Claude Fable 5 from an organization whose data retention configuration does not meet this requirement return a 400 invalid_request_error:

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "In order to access this model, your organization or workspace must have data retention enabled."
  }
}

The 30-day data retention requirement applies wherever Covered Models are offered. On the Claude API (including Claude Platform on AWS), Anthropic handles retained data. On Amazon Bedrock and Google Cloud's Agent Platform, retained data stays within your cloud provider's environment; review each platform's documentation for enablement steps.

Enable 30-day retention for a workspace

Organizations with a ZDR arrangement can make these models available in a specific workspace by enabling 30-day retention for that workspace only. Other workspaces in the organization keep zero data retention.

1. 1

   Open the workspace's data retention settings

   In the Claude Console, go to the Data retention page (platform.claude.com/settings/privacy) and select the workspace from the dropdown menu at the top of the page.

2. 2

   Turn on 30-day data retention

   Select Standard data retention (30-day retention) and click Save. A confirmation dialog box then asks you to review and accept the terms that apply to data retention for the workspace. Data retention turns on for the workspace only after you accept them.

3. 3

   Verify

   Requests to Covered Models from this workspace now succeed. Workspaces without an override continue to follow the organization default.

Feature eligibility

The following table lists which Claude API features are eligible for ZDR and HIPAA readiness arrangements.

Each eligibility column uses three values:

• Yes: The feature is fully eligible under the arrangement. For ZDR, "Yes" also assumes you are using a model that does not require 30-day data retention; Covered Models are not available under ZDR regardless of feature eligibility.
• Yes (qualified): Your prompts and Claude's outputs are not stored, but a bounded technical artifact (named in the Details column) is retained briefly for the feature to function. See How Anthropic approaches data retention for the commitments that govern these features.
• No: The feature is not eligible. Under HIPAA readiness, the API blocks requests that include a "No" feature and returns a 400 error, unless the feature's Details column says otherwise. Under ZDR, the API does not block these features; using one is a choice to step outside your ZDR arrangement for that specific data, and the feature's own documented retention policy applies. Features marked "No" for ZDR are typically stateful (they store jobs, files, or container state), which is why they cannot be zero-retention.