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

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

列出組織

List organizations 端點會回傳金鑰所綁定之上層組織底下的每個組織。

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

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。

列出組織使用者

List organization users 端點會回傳某一組織的分頁使用者記錄清單。

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

有關 limit 與 page 查詢參數的預設值與範圍，請參閱 API 參考中的 List organization users。

結果依加入組織的日期遞增排序。與 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": "priya@example.com",
      "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_... 識別碼相同；本機工作階段清單沒有使用者篩選條件，因此請依每個工作階段物件上的 user.id 來歸屬本機工作階段。organization_role 欄位帶有使用者在所列組織中的內建成員層級（admin、billing、claude_code_user、developer、managed、membership_admin、owner、primary_owner 或 user 其中之一），這是一個獨立於 列出角色 所回傳之任何自訂 RBAC 角色指派的維度。典型的 eDiscovery 流程會列出一個或多個組織的使用者、依您自己的外部記錄進行篩選，然後將得到的 ID 送入聊天與專案查詢。

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

列出角色

List Compliance Roles 端點會回傳某一組織上所定義之角色記錄的分頁清單，而 Get Compliance Role 則依 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
}

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

列出群組與成員

List Compliance Groups 端點會回傳 RBAC 與 SCIM 佈建群組的分頁清單，而 Get Compliance Group 則依 ID 回傳單一群組。List Compliance Group Members 端點會回傳某一群組的成員。

群組清單與擷取端點需要 read:compliance_org_data。成員端點需要 read:compliance_user_data。請在建立金鑰時同時賦予這兩個範圍，以便完整走訪群組。兩個清單端點皆接受與組織使用者端點相同的 limit 與 page 參數。

有關完整的群組記錄結構，請參閱 List Compliance Groups 回應結構描述。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": "priya@example.com",
      "created_at": "2025-06-01T10:00:00Z",
      "updated_at": "2025-06-15T14:30:00Z"
    }
  ],
  "has_more": false,
  "next_page": null
}

有關完整的成員記錄結構，請參閱 List Compliance Group Members 回應結構描述。user_id 欄位與 Activity Feed、聊天清單及遠端工作階段清單所接受的 user_... 識別碼相同；它也與本機工作階段物件以及使用者擁有之遠端工作階段物件上的 user.id 相符（代理擁有的遠端工作階段則改以 started_by_user.id 帶有該人員的 ID）。若要取得成員的全名，請透過組織使用者清單查詢。

取得有效組織設定

Get effective organization settings 端點會回傳您上層組織底下某一組織的生效設定：即套用法規限制（例如 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 參考中的 Get effective organization settings。

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 稽核誰在何時變更了什麼。

後續步驟