設計您的合規整合

一個正式環境的 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 key。



規劃內容保留

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

關於 Claude Platform 其餘部分如何處理保留，請參閱 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 常見問題。

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



後續步驟