> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usehasp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# The store Flag

> What store: false does and does not do — no content storage is not the same as no retention.

The `store` flag behaves differently depending on which surface you use.

## Native surface (`POST /v1/ai/chat`)

The native surface **accepts** `store` as an optional boolean parameter (default `true`).

| Value                   | Behavior                                                                                                                                              |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| `store: true` (default) | Response content is stored in the inference record and returned by `GET /v1/ai/messages/{id}`.                                                        |
| `store: false`          | A shell row is still created (for auditability) but no message content is stored. `GET /v1/ai/messages/{id}` returns the record with `content: null`. |

In both cases the audit log entry is created and token usage is recorded. `store: false` only suppresses content persistence — it does not suppress billing, PHI scanning, or audit events.

## Anthropic-compat surface (`POST /v1/messages`)

The compat surface **rejects** requests that include a `store` field. This is a deliberate guardrail.

The Anthropic API uses `store: false` to opt out of training data collection. On the HASP compat surface that parameter has no meaningful analog — HASP's data handling is governed by your BAA and retention policy, not by a per-request flag. Accepting `store: false` silently would mislead callers into thinking they had opted out of some HASP-specific storage behavior.

Instead, the API returns a 400 error:

```json theme={null}
{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "The `store` parameter is not supported on the HASP compat surface. Remove it from your request.",
    "hasp_code": "UNSUPPORTED_PARAMETER",
    "hasp_details": {
      "param": "store"
    }
  }
}
```

## What HASP stores and retains

Regardless of the `store` flag, HASP's retention behavior is determined by your organization's **data retention policy** configured at the organizational level:

| What                                          | Where                                | Retention                                              |
| --------------------------------------------- | ------------------------------------ | ------------------------------------------------------ |
| Request payload (messages, model, parameters) | Encrypted at rest (Aptible Postgres) | Per your retention policy (default: 7 years for HIPAA) |
| Response content                              | Same                                 | Same — unless `store: false` on the native surface     |
| PHI redaction metadata                        | Same                                 | Same                                                   |
| Audit log entry                               | Tamper-resistant audit chain         | Permanent (per ADR-JVSATA)                             |
| Token usage                                   | Usage table                          | Permanent (for billing)                                |

**The audit log entry is always retained.** Even if your retention policy is set to the minimum, the audit log records that a request was made, who made it, what model was used, and what compliance events fired. This is a regulatory requirement and cannot be disabled.

## Disabling content storage

If your use case requires inference without content retention, configure **Storage Mode: None** in **Settings → AI Workspace → Data Retention**. This instructs HASP to perform inference without persisting the message payload. The audit log entry is still created.

Note: With storage disabled, `GET /v1/ai/messages/{id}` returns the record but not the message content. The `request_id` remains valid and usable for support purposes.

## Migrating from @anthropic-ai/sdk with store: false

If your existing code passes `store: false` to the Anthropic SDK and you're pointing it at the HASP compat surface (`/v1/messages`), remove the `store` field:

```diff theme={null}
  const msg = await client.messages.create({
    model: 'claude-sonnet-4-6',
    messages: [...],
-   store: false,
  });
```

Then configure your organization's data retention policy in the dashboard to match your compliance requirements. If you need to suppress content storage per-request, use the native `/v1/ai/chat` surface with `store: false`.