設計您的合規整合

生產環境的 Compliance API 整合需要做出三項設計決策：如何消費 Activity Feed、其輸出如何與您的「security information and event management」（安全資訊與事件管理），即 SIEM 系統進行關聯，以及活動與內容的長期副本存放於何處。這些決策與端點本身無關；本頁面將協助您評估各種權衡取捨。

本頁面假設您已閱讀查詢 Activity Feed，該文件定義了本文通篇引用的參數與分頁契約，以及擷取與刪除對話、檔案和專案，該文件定義了規劃內容保留中引用的內容端點與 deleted_at 語意。

選擇 Feed 消費模式

Activity Feed 支援兩種消費模式：以 created_at.gte 和 created_at.lt 為界的週期性視窗輪詢，以及游標驅動的增量讀取（從一個回應中保存游標並在下一個請求中傳遞）。兩者都會回傳相同的 Activity 物件；差異在於您的用戶端在呼叫之間所保存的狀態。

兩種模式共享以下限制：

• 活動在發生後 1 分鐘內即可查詢，並保留 6 年。
• 每頁的最大 limit 為 5,000。
• 游標值是不透明的字串，您不得解析。
• 請求限制為每個父組織每分鐘 600 次，由每個金鑰、每個連結的組織以及每個 /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 進行去重，並且擴大每個新視窗使其與前一個視窗重疊幾分鐘，或執行定期的對帳程序以重新查詢較舊的視窗。

游標驅動的增量讀取

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)

游標在金鑰輪替後仍然有效；請參閱管理與輪替金鑰。

與您的 SIEM 進行關聯

每個 Activity 都帶有可與您 SIEM（Splunk、Datadog、Microsoft Sentinel、Cribl 或類似系統）中既有事件進行聯結的欄位：

當 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 金鑰。

規劃內容保留

三個保留期限決定了您日後可以擷取的內容：

有關 Claude 平台其餘部分如何處理保留，請參閱 API 與資料保留。

請依以下方式在匯出並封存與按需 API 擷取之間做出決定：

• 如果您的法律保全或稽核期限超過活動中繼資料的 6 年，請在擷取 Activity Feed 頁面時將其匯出至您自己的封存。
• 如果您的內容保留政策短於您的電子蒐證期限，請在保留視窗到期前匯出對話和檔案內容；Compliance API 無法回傳保留政策已移除的內容。
• 如果某個工作流程可能發出 Compliance API 硬刪除（例如 DLP 強制執行），請先擷取並封存目標內容。硬刪除後沒有恢復視窗；來自 claude.ai 的軟刪除仍可擷取且 deleted_at 會被填入，但 Compliance API 的刪除則不會。

在其他所有情況下，請依賴直接 API 擷取，避免維護平行副本。

傳遞保證與完整性

請將 Activity Feed 視為至少一次傳遞：正確分頁的遍歷會至少回傳每個活動一次，但在部分失敗後的重試可能會重新傳遞您已儲存的活動。請依活動 id 欄位進行去重。

列表端點不會回傳 total_count 欄位或校驗和。若要證明匯出執行已完成，請記錄：

• 起始游標與終止的 last_id。
• 匯出的記錄數量。
• 執行時間戳記與最後一頁的 request-id。

內容端點（對話、檔案、專案和專案附件）僅提供 claude.ai 資料；Activity Feed 則呈現整個組織範圍的管理與資源事件。Compliance API 不包含：

• 來自 Claude Console 或 Claude API 工作負載的提示文字或模型回應。
• 被您組織的保留政策移除的內容。
• 透過 Compliance API 硬刪除的內容。

有關 Compliance API 涵蓋與不涵蓋內容的更多資訊，請參閱 Compliance API 常見問題。

為了保管鏈，請將匯出的記錄與來源中繼資料一併儲存：來源端點、查詢參數、執行時間戳記，以及每筆記錄的內容雜湊。

後續步驟