從 Beta 版遷移

最近一次更新： 2026年8月20日

本文適用於以 Beta 存取模型建立的組織——在此模型下，管理員須逐一向每位成員授予權限。存取權限現以 Workflow Profiles 及 Account Roles 為基礎，Kraken 將為您自動完成組織轉換。

在轉換前，請注意以下兩點：

  • 如您使用 API 金鑰，請檢查其組織行為。現有 API 呼叫將繼續在主要帳戶上執行。請使用 account_id 選擇其他帳戶，並將提款呼叫成功視為請求已提交，而非資金已轉移的確認。請參閱下方「檢查您的 API 行為」。
  • 我們將請您確認已準備就緒。組織須待您接受變更後，方會進行轉換。

轉換過程不會移除任何存取權限。每位成員原有的所有權限均會一併保留。

您現有的 API 金鑰不會被撤銷或重新發放。其登入憑證、權限及帳戶對應關係均會完整保留。未傳入 account_id 的現有呼叫，將繼續在組織的主要帳戶上運作。請檢查您的整合如何選擇其他帳戶，以及如何讀取提款回應。

如需指定特定帳戶

若省略 account_id，私有請求將在主要帳戶上執行：

bash

Bash

POST /0/private/AddOrder

如需對特定帳戶執行操作，請在 URL 中以查詢參數形式傳入 account_id：

bash

Bash

POST /0/private/AddOrder?account_id=W5PB62NTPNYT6TYH

請在 URL 傳入此參數，而非置於請求正文中。明確指定的 account_id 優先於主帳戶的備用預設值。此操作不會擴展金鑰的帳戶對應範圍或權限。

解讀新的提款回應

WithdrawFunds 會同時回傳 approval_request_id 及 refid：

bash

Bash

{
  "error": [],
  "result": {
    "refid": "FTcLNGa-4ZWmo4GCo8wrBNZz5v53v9",
    "approval_request_id": "656a021a-1d55-42c9-853a-aea57bf5abd1"
  }
}
  • refid 不再代表提款已完成。請求提交後，相應金額將在來源帳戶鎖定，待請求獲批准後方可結算。
  • approval_request_id 是追蹤該提款審批的識別碼。請將其與您的記錄一併保存。
  • 待審批的提款請求不會顯示於 WithdrawStatus。遭拒絕或已到期的請求不會產生任何提款記錄，因此在 WithdrawStatus 中查無結果，並不代表提款從未提交。

若自動化系統將 refid 視為提款完成的憑證，在提款仍待審批期間，系統將錯誤地將其報告為已結算。完整模型詳情，請參閱 API 金鑰。

轉換完成後，您的 Organization 將包含兩組標準元素。

Workflow Profiles

Workflow Profile 設定成員在每個工作流程中可執行的操作。每位成員僅持有一個。

個人資料

所含權限

管理員

所有工作流程的所有層級，包括 Execute

發起人

所有工作流程的 View 及 Initiate 權限。無法審批

Approver

所有工作流程的 View 及 Approve 權限。無法發起

Auditor

所有工作流程的 View 權限。無法操作

Funds Manager

可對 Withdrawal Request 及 Transfer Request 執行查看、發起及審批操作。可對 Manage Addresses 執行查看及發起操作

帳戶角色

帳戶角色設定成員可對您的帳戶執行哪些操作。標準角色涵蓋所有現有及未來的帳戶，因此擁有「交易全部」角色的成員，可在您明天新建的帳戶上進行交易。

角色

授予每個帳戶的權限

讀取全部

閱讀

交易全部

交易

資金全部

轉帳、提領、理財配置、理財取消配置

完全存取權限

所有帳戶權限

標準設定檔與角色會隨產品同步更新：每當新增工作流程時，持有相應設定檔或角色的成員會自動獲得對應權限級別。如需了解完整模型，請參閱 角色、設定檔與權限。

若成員的權限與任何標準設定檔均不相符，系統會為其建立一個角色，完整保留其原有權限。權限完全相同的成員將共用同一個角色，因此您的機構擁有的角色數量將遠少於成員數量。

這些角色的名稱取自您為成員所填寫的標籤，例如標籤為「Trader」的成員，其對應角色將命名為 trader。未設有標籤的成員將歸入 migrated-role。每個角色均帶有 migrated 標記，表示名稱由系統自動生成，您可自行修改。

貼士：

轉換完成後，建議您首先將這些角色重新命名，以符合實際的稱呼習慣。編輯角色後，系統將自動清除 migrated 標記。

為何您的「Admin」成員未被歸入 Admin 設定檔

Beta 版的「Admin」標籤允許成員查看、發起及審批請求，但無法在未經第二次審批的情況下完成自己提交的請求。Admin 設定檔確實包含該能力，即「執行」（Execute）級別。

為免自動授予此權限，擁有舊標籤的成員將被歸入名為 beta-admin 的角色，該角色完整保留其原有權限。如需將其移至 Admin，只需進行一次重新指派即可，時機由您決定。

註：

beta-admin 是您自訂角色之一，持有該角色的成員不會像標準設定檔般自動套用新工作流程。這也是建議您在轉換後盡快檢視這些角色的原因之一。

擁有者將套用 Admin 設定檔，保留原有的所有設定，並自動套用新工作流程。擁有者同時持有 Read all 權限，此權限無法移除。

如果您曾刻意縮減擁有者的權限，該設定將予以保留：擁有者將轉換為持有其實際權限的角色，與其他成員相同。

  • 每位成員原有的所有權限均會一併保留。
  • API 金鑰的登入憑證、權限及帳戶對應均予以保留。
  • 餘額、帳戶及帳戶所有權均不受影響。
  • 進行中的審批請求將繼續處理，您的政策、審批門檻及「始終要求審批」設定均保持不變。
  • 身份驗證不受影響，任何人均無需重新登入或重新接受邀請。
  • 只有屬於您機構的帳戶才會轉換。機構以外的任何帳戶權限均維持原狀。

疑難排解

未傳入 account_id 的請求將使用機構的主要帳戶。如需查詢金鑰帳戶對應中的其他帳戶，請在 URL 中傳入該帳戶的 account_id。請參閱「按需選擇特定帳戶」。

此請求已成功建立，相應金額已在原帳戶鎖定。資金將於批准後完成結算。請使用此 API 呼叫回傳的 approval_request_id 追蹤請求，或前往「請求」頁面查閱。請參閱 轉帳與提款。

權限與標準設定檔不符的成員，各自需要一個保留其原有存取權限的角色；只有當兩位成員的權限完全相同時，才會合併至同一個角色。即使權限相符，曾被賦予不同標籤的成員仍會保留在各自的角色中，因為不同標籤意味著這種區分是有意為之的。不再需要的角色，可將其成員重新分配至其他角色後刪除，以整合角色設定。

負責管理組織的成員（包括管理團隊存取權限、帳戶或 API 金鑰）將自動獲分配「讀取全部」角色，因為管理帳戶本身即代表需要查看該帳戶的權限。若此範圍超出實際需要，可將「讀取全部」替換為僅限特定帳戶的帳戶角色。

不可以。此轉換為單向操作。轉換後產生的所有設定均可編輯，因此您原有的任何存取安排均可透過設定檔和角色重新建立。

相關文章