列出組織、使用者、角色、群組和設定

本頁的端點公開了 Claude Enterprise 組織的目錄面向：其連結的組織、每個組織中的使用者、每個組織上定義的角色，以及其「role-based access control」（角色型存取控制），即 RBAC，或「SCIM (System for Cross-domain Identity Management)」佈建的群組及其成員。使用它們來建立 eDiscovery 使用者清單、建置報告儀表板，以及將群組成員資格與外部記錄系統進行核對。涵蓋父組織的 Compliance Access Key 會回傳其下每個連結組織的資料，因此單一金鑰即可觸及整個樹狀結構。有效設定端點補足了目錄功能：它回傳一個組織實際生效的資料隱私、安全性和功能設定。



列出組織

列出組織端點會回傳金鑰所繫結的父組織下的每個組織。

以下呼叫會列出您父組織下的每個組織。回應是一個依 created_at 遞增排序的組織記錄 data 陣列，加上用於分頁的 has_more 和 next_page。當 has_more 為 true 時，將回傳的 next_page 權杖原封不動地作為下一個請求的 page 查詢參數傳回。請參閱 API 參考中的列出組織以了解 limit 和 page 參數的預設值和範圍。

curl --fail-with-body -sS \
  "https://api.anthropic.com/v1/compliance/organizations" \
  -H "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY"

{
  "data": [
    {
      "uuid": "91012d09-e48b-438e-a489-1bebfd8fa6f9",
      "name": "Acme Engineering",
      "created_at": "2025-06-01T10:00:00Z"
    },
    {
      "uuid": "5a1b2c3d-4e5f-6789-abcd-ef0123456789",
      "name": "Acme Legal",
      "created_at": "2025-07-15T14:30:00Z"
    }
  ],
  "has_more": false,
  "next_page": null
}

uuid 欄位是用於下游查詢的標準識別碼。下表將其對應到 Compliance API 中的其他組織識別碼：

大多數其他 Anthropic API 使用帶有 org_ 前綴的形式。

若要追蹤組織成員資格隨時間的變化，請定期重新列出此端點，並在每次執行時透過 next_page 權杖遍歷每一頁。Activity Feed 也會透過 org_deletion_requested、org_deleted_via_bulk、org_parent_join_proposal_created 和 org_join_proposal_decided 活動類型顯示成員資格事件；請參閱查詢 Activity Feed。



列出組織使用者

列出組織使用者端點會回傳一個組織的使用者記錄分頁清單。

此端點需要 read:compliance_user_data，而非 read:compliance_org_data。當您打算將 Compliance Access Key 用於目錄列舉時，請在建立時同時包含這兩個範圍；否則呼叫會回傳 403 Forbidden。

請參閱 API 參考中的列出組織使用者以了解 limit 和 page 查詢參數的預設值和範圍。

結果依組織加入日期遞增排序。與 Activity Feed 的 before_id/after_id 游標（請參閱分頁結果）不同，目錄端點使用 next_page 權杖進行分頁：當 has_more 為 true 時，將 next_page 原封不動地作為下一個請求的 page 查詢參數傳回。

org_uuid="91012d09-e48b-438e-a489-1bebfd8fa6f9"

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/organizations/$org_uuid/users" \
  -H "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --data-urlencode "limit=500"

{
  "data": [
    {
      "id": "user_01XyDMpzjS89pFZXqSFUBDr6",
      "full_name": "Priya Sharma",
      "email": "[email protected]",
      "organization_role": "admin",
      "created_at": "2025-06-01T10:00:00Z"
    }
  ],
  "has_more": true,
  "next_page": "page_8aW5kZXgicG9zaXRpb25fdG9rZW5fOTE0"
}

此處回傳的使用者 ID 與查詢 Activity Feed 的 actor_ids[] 篩選器以及擷取聊天和訊息的 user_ids[] 篩選器所接受的 user_... 識別碼相同。organization_role 欄位帶有使用者在所列組織中的內建成員資格層級（admin、billing、claude_code_user、developer、managed、membership_admin、owner、primary_owner 或 user 其中之一），這是一個獨立於列出角色所回傳的任何自訂 RBAC 角色指派的維度。典型的 eDiscovery 流程會列出一個或多個組織的使用者，與您自己的外部記錄進行篩選比對，然後將產生的 ID 輸入到聊天和專案查詢中。

使用者只有在是組織的活躍成員時才會出現在此處。被移除的使用者會立即從清單中刪除。他們的歷史活動在完整的保留期間內仍可透過 Activity Feed 查詢，並以相同的 user_... ID 建立索引。



列出角色

列出 Compliance 角色端點會回傳一個組織上定義的角色記錄分頁清單，而取得 Compliance 角色會依 ID 回傳一個角色。

兩個角色端點都需要 read:compliance_org_data。清單端點接受與組織使用者端點相同的 limit 和 page 參數。

org_uuid="91012d09-e48b-438e-a489-1bebfd8fa6f9"

curl --fail-with-body -sS \
  "https://api.anthropic.com/v1/compliance/organizations/${org_uuid}/roles" \
  -H "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY"

{
  "data": [
    {
      "id": "rbac_role_01N2pQrS8tUvWxYz5AbCdEfGh",
      "name": "Compliance Reviewer",
      "description": "Read-only access to chat and project content for legal review.",
      "created_at": "2025-06-01T10:00:00Z",
      "updated_at": "2025-06-15T14:30:00Z"
    }
  ],
  "has_more": false,
  "next_page": null
}

請參閱列出 Compliance 角色回應結構描述以了解完整的角色記錄格式。若要列出目前授予某個角色的權限，請使用列出 Compliance 角色權限。若要稽核歷史角色指派和權限變更，請透過 Activity Feed 查詢 RBAC 活動類型（例如 rbac_role_assigned 和 rbac_role_permission_added）；請參閱篩選活動。



列出群組和成員

列出 Compliance 群組端點會回傳 RBAC 和 SCIM 佈建群組的分頁清單，而取得 Compliance 群組會依 ID 回傳一個群組。列出 Compliance 群組成員端點會回傳一個群組的成員。

群組清單和擷取端點需要 read:compliance_org_data。成員端點需要 read:compliance_user_data。建立金鑰時請同時包含這兩個範圍，以便完整遍歷群組。兩個清單端點都接受與組織使用者端點相同的 limit 和 page 參數。

請參閱列出 Compliance 群組回應結構描述以了解完整的群組記錄格式。roles 陣列列出指派給該群組的角色 ID，與列出角色中的 ID 相符。source_type 是區分透過 claude.ai 手動建立的群組（direct）和透過 SCIM 從外部身分識別提供者同步的群組（scim）的判別欄位。

列出群組，然後針對每個群組列出其成員：

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/groups" \
  -H "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY"

{
  "data": [
    {
      "id": "rbac_group_01P9qRsTuVwXyZa2BcDeFgHjK",
      "name": "Engineering",
      "description": "Engineering team members",
      "source_type": "scim",
      "roles": ["rbac_role_01N2pQrS8tUvWxYz5AbCdEfGh"],
      "created_at": "2025-06-01T10:00:00Z",
      "updated_at": "2025-06-15T14:30:00Z"
    }
  ],
  "has_more": false,
  "next_page": null
}

針對每個群組 ID，列出其成員：

group_id="rbac_group_01P9qRsTuVwXyZa2BcDeFgHjK"

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/groups/$group_id/members" \
  -H "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY"

{
  "data": [
    {
      "user_id": "user_01XyDMpzjS89pFZXqSFUBDr6",
      "email": "[email protected]",
      "created_at": "2025-06-01T10:00:00Z",
      "updated_at": "2025-06-15T14:30:00Z"
    }
  ],
  "has_more": false,
  "next_page": null
}

請參閱列出 Compliance 群組成員回應結構描述以了解完整的成員記錄格式。user_id 欄位與 Activity Feed 和聊天清單所接受的 user_... 識別碼相同。若要取得成員的全名，請透過組織使用者清單查詢。



取得有效組織設定

取得有效組織設定端點會回傳您父組織下某個組織生效中的設定：在套用法規限制（例如 HIPAA）、功能可用性規則、組織類型預設值和功能間相依性之後的強制執行狀態，這可能與管理員所設定的不同。使用它來證明保留期間、內容遮蔽、單一登入強制執行、IP 允許清單和工作階段持續時間控制符合您記錄的基準，而無需管理員的 Console 存取權。

此端點需要 read:compliance_org_data；沒有該範圍的金鑰會回傳 403 Forbidden。目標必須是父組織的連結組織之一：父組織本身不是有效的目標。未知的組織、不是有效 UUID 的組織 ID、您父組織樹狀結構之外的組織，以及尚未取得此端點存取權的父組織，都會回傳相同的 404 Not Found，因此 404 不會透露組織是否存在。設定端點是針對每個父組織與 Compliance API 的其餘部分分開啟用的；如果每個請求都回傳 404，請聯絡您的 Anthropic 代表。

org_uuid="91012d09-e48b-438e-a489-1bebfd8fa6f9"

curl --fail-with-body -sS \
  "https://api.anthropic.com/v1/compliance/organizations/$org_uuid/settings" \
  -H "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY"

回應是一個具型別的設定列清單，而出現哪些列會因組織而異：組織管理員無法變更的設定（因為它由 Anthropic 政策控制或該組織無法使用）會從清單中省略。請將缺少的列視為「此組織的管理員無法控制」，而非「關閉」。以下簡化範例顯示回應可能包含的三個列：

{
  "type": "effective_organization_settings",
  "organization_id": "91012d09-e48b-438e-a489-1bebfd8fa6f9",
  "settings": [
    {
      "name": "data_retention_periods",
      "type": "data_retention",
      "value": {
        "chat": {
          "type": "fixed",
          "timescale": "day",
          "duration": 90
        }
      }
    },
    {
      "name": "content_redaction_enabled",
      "type": "boolean",
      "value": true
    },
    {
      "name": "ip_allowlist_ip_ranges",
      "type": "string_list",
      "value": ["10.0.0.0/8", "203.0.113.0/24"]
    }
  ],
  "api_keys": [
    {
      "type": "compliance_api_key",
      "id": "apikey_01Hx7k2mP9nQ4rS6tU8vW0xY",
      "name": "Compliance Export Key",
      "scopes": ["read:compliance_activities", "read:compliance_org_data"],
      "is_active": true,
      "created_at": "2026-03-14T09:30:00Z",
      "created_by_id": "user_01Jz3a4bC5dE6fG7hI8jK9lM",
      "expires_at": null
    }
  ]
}

每一列都帶有 name、type 和 value；type 欄位（boolean、integer、string_list、provisioning_mode 或 data_retention）告訴您 value 的格式。完整的設定名稱清單以及每種類型的 value 結構描述，請參閱 API 參考中的取得有效組織設定。

api_keys 陣列列出為您的父組織設定的每個 Compliance Access Key，因此無論您查詢哪個連結組織，都會回傳相同的清單。每個項目都帶有金鑰的 type（compliance_api_key）、id、name、scopes、is_active 旗標、created_at 和 expires_at 時間戳記，以及 created_by_id（建立金鑰的使用者 ID；可能為 null）。金鑰的秘密值永遠不會被回傳。已停用的金鑰會以 is_active: false 包含在內，以便您檢視先前擁有存取權的金鑰，而僅帶有已停用的 read:compliance_org_settings 範圍的金鑰仍會保留在清單中，以供稽核和清理可見性之用，即使該範圍不再授予存取權。

頂層的 organization_id 是組織的純 UUID：與組織清單中的 uuid 值相同，而非 organization_id 在 Activity Feed、聊天和專案記錄上所帶有的 org_ 前綴形式（請參閱組織識別碼表格）。

這些列反映的是強制執行狀態，而非最後儲存的設定：例如，sso_provisioning_mode 只有在目錄同步啟用時才會回報已設定的 SCIM 模式，ip_allowlist_enabled 只有在允許清單開啟且至少有一個作用中範圍時才為 true，而 code_execution_network_egress_enabled 在程式碼執行關閉時一律為 false。

回應反映的是讀取時的狀態；不會建立任何快照。這些設定中大多數的變更會以事件形式出現在 Activity Feed 中；使用此端點取得目前的解析狀態，並使用 Activity Feed 稽核誰在何時變更了什麼。



後續步驟