要启用 Compliance API,请参阅设置 Compliance API。
**所需权限范围:**Compliance Access Key 或 Admin API 密钥上的 read:compliance_activities。
生产环境的 Compliance API 集成需要做出三项设计决策:如何消费活动信息流(Activity Feed)、其输出如何与您的 "security information and event management"(安全信息和事件管理),即 SIEM 系统进行关联,以及活动和内容的长期副本存储在何处。这些决策与端点本身无关;本页面将帮助您评估各种权衡取舍。
本页面假定您已阅读查询活动信息流(其中定义了本文通篇引用的参数和分页约定),以及检索和删除聊天、文件和项目(其中定义了内容端点和规划内容保留中引用的 deleted_at 语义)。
活动信息流支持两种消费模式:由 created_at.gte 和 created_at.lt 限定的周期性窗口轮询,以及游标驱动的增量读取(持久化保存一个响应中的游标并在下一个请求中传递)。两者返回相同的 Activity 对象;区别在于您的客户端在调用之间持久化的状态。
两种模式都有以下共同约束:
limit 为 5,000。/v1/compliance/* 端点之间共享;有关响应标头和重试约定,请参阅 429 Too Many Requests。| 模式 | 适用场景 |
|---|---|
| 窗口轮询 | 您的管道按固定计划运行,您偏好无状态的工作进程,并且可以容忍重放或重叠的窗口 |
| 游标驱动的增量读取 | 您希望活动发生与管道摄取之间的延迟最低,希望避免重新读取已处理完的页面,并且有可靠的位置在运行之间持久化游标 |
将 created_at.lt 设置为至少早于当前时间 1 分钟,以确保窗口内的每个活动都已可查询。使用 created_at.gte 作为下界,created_at.lt 作为上界,使连续的窗口无缝拼接且不重叠;将上一个窗口的 lt 值复用为下一个窗口的 gte。
curl --fail-with-body -sS -G \
"https://api.anthropic.com/v1/compliance/activities" \
--header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
--data-urlencode "created_at.gte=2026-04-20T07:00:00Z" \
--data-urlencode "created_at.lt=2026-04-20T08:00:00Z" \
--data-urlencode "limit=5000"当响应中 has_more: true 时,该窗口包含的活动超过一页。您可以通过将响应的 last_id 作为下一个请求的 after_id 传递来在窗口内分页(当 has_more 为 false 时停止),或者选择更小的时间窗口。有关完整约定,请参阅对结果进行分页。
即使窗口拼接得严丝合缝,在其所属窗口关闭后才完成索引的活动也永远不会出现在后续窗口中。请基于活动 id 进行去重,并且要么扩大每个新窗口使其与前一个窗口重叠几分钟,要么定期运行一次对账流程以重新查询较早的窗口。
created_at.lt 边界过于接近当前时间会静默且永久地丢弃延迟索引的活动:一旦 created_at.gte 推进超过它们,后续任何窗口都无法恢复它们。请将 1 分钟的可查询性数值视为文档规定的索引延迟,而非软性建议。
first_id="activity_01XyDMpzjS89pFZXqSFUBDr6" # first_id from a previous response
curl --fail-with-body -sS -G \
"https://api.anthropic.com/v1/compliance/activities" \
--header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
--data-urlencode "limit=5000" \
--data-urlencode "before_id=$first_id"持续分页直到 has_more 为 false,然后持久化最终响应中的 first_id,并在下次运行时将其原样作为 before_id 传递,以检索比已保存游标更新的活动。如需反向遍历以进行回填,则改为持久化 last_id 并将其作为 after_id 传递。有关游标与页面令牌的完整参考以及重试语义,请参阅对结果进行分页。
生产环境的追赶循环通过基于 has_more 和 first_id 驱动迭代,来获取自上次轮询以来记录的活动:
cursor = stored_cursor
loop:
page = GET /v1/compliance/activities?before_id={cursor}&limit=5000
store(page.data)
if page.first_id is not null:
cursor = page.first_id
if not page.has_more: break
persist(cursor)游标在密钥轮换后仍然有效;请参阅管理和轮换密钥。
每一页都与您传递的游标相邻:该循环一次一页地向当前时间方向前进。当 has_more 为 true 时,不要将单个响应视为已追赶完成。仅在 has_more 为 false 后才持久化游标;未获取的页面是位于此响应的 first_id 与当前时间之间的较新页面,在您完成循环或再次运行之前,它们将保持未读状态。
每个 Activity 都携带可与您 SIEM(Splunk、Datadog、Microsoft Sentinel、Cribl 或类似系统)中已有事件进行关联的字段:
| Compliance API 字段 | 关联目标 |
|---|---|
actor.user_id | 您的身份提供商的稳定用户标识符 |
actor.email_address | 当稳定 ID 不可用时的目录电子邮件 |
actor.ip_address | 网络、VPN 和端点日志 |
created_at | 跨任何来源的时间窗口关联 |
当 actor.type 为 user_actor 时,actor.user_id 和 actor.email_address 才会存在;在读取它们之前请检查该判别字段。user_id 是用户账户的稳定、不透明标识符:它在所有 Compliance API 端点和活动负载中保持一致,并且在用户的电子邮件或显示名称更改时不会改变。请使用 user_id 而非 email_address 作为主要关联键。
对 Compliance API 本身的调用会产生 compliance_api_accessed 活动。请将这些活动与其他活动类型一起摄取,以便您的 SIEM 记录谁在何时查询了合规数据。传递 activity_types[]=compliance_api_accessed 以限定查询范围,然后在您的客户端中,从每个 actor.type 为 api_actor 的活动中读取 actor.api_key_id,以将访问归因到特定的 Compliance Access Key 或 Admin API 密钥。
三个保留期限决定了您之后可以检索的内容:
| 数据 | 保留期限 | 控制方 |
|---|---|---|
| 活动信息流记录 | 6 年 | Anthropic |
| 聊天、文件和项目内容 | 您组织的 claude.ai 保留策略 | 您的组织 |
| 通过 Compliance API 硬删除的内容 | 不保留;删除是立即且永久的 | DELETE 端点的调用方 |
有关 Claude 平台其余部分如何处理数据保留,请参阅 API 和数据保留。
请按以下方式在"导出并归档"与"按需 API 检索"之间做出选择:
deleted_at 会被填充,但 Compliance API 删除则不会。在所有其他情况下,请依赖直接 API 检索,避免维护并行副本。
请将活动信息流视为至少一次交付:正确分页的遍历会至少返回每个活动一次,但在部分失败后的重试可能会重新交付您已存储的活动。请基于活动 id 字段进行去重。
列表端点不返回 total_count 字段或校验和。要证明某次导出运行是完整的,请记录:
last_id。request-id。内容端点(聊天、文件、项目和项目附件)仅提供 claude.ai 数据;活动信息流则呈现组织范围内的管理和资源事件。Compliance API 不包括:
有关 Compliance API 捕获和不捕获内容的更多信息,请参阅 Compliance API 常见问题解答。
对于监管链(chain of custody),请将导出的记录与来源元数据一起存储:源端点、查询参数、运行时间戳以及每条记录的内容哈希。
Was this page helpful?