API 密鑰

API 金鑰並非持有登入憑證的成員。API 金鑰採用獨立且更簡單的權限模型：

兩種模型刻意保持分離。成員擁有角色、設定檔及按帳戶細分的權限，因為人員會隨時間承擔多樣化的職責。金鑰採用扁平的權限加帳戶模型，確保自動化操作保持精簡、統一，審計時一目了然。

API 金鑰包含兩項設定：可執行的操作（權限）及操作範圍（帳戶）。

權限

帳戶對應

每個金鑰在建立時即對應一個或多個帳戶，日後可隨時編輯。金鑰的權限會統一套用至所有已選帳戶：

• 若某金鑰同時擁有兩個帳戶的「查詢資金」及「建立並修改訂單」權限，則可在這兩個帳戶中查看餘額及進行交易，不能執行其他操作。
• 單一金鑰不支援按帳戶設定不同權限。若自動化系統需要在某帳戶執行交易、僅在另一帳戶讀取資料，請使用兩個金鑰。如此可清晰界定每個金鑰的影響範圍。

FIX 連線

擁有訂單權限的金鑰可透過 FIX 協議進行現貨交易，與 REST 及 WebSocket API 並行使用。FIX 交易時段的權限及帳戶對應與所使用的金鑰相同：僅能在該金鑰已選定的帳戶範圍內進行交易。透過 FIX 執行訂單流的機構通常為每個時段分配一個專用金鑰，並將其限定於該交易台所使用的帳戶。

安全設定

Organization 治理適用於金鑰的操作行為及其管理方式。

金鑰的操作

適用於成員的兩類規則同樣適用於金鑰：

• 直接操作即時執行。交易、理財、餘額查詢、分類帳查詢及資料匯出，均在金鑰的權限及帳戶範圍內即時完成。
• 受治理操作將建立請求。由金鑰發起的提款或地址變更，與成員發起的請求進入相同的處理流程：工作流程的政策將決定其是否即時完成，或進入審批佇列等待人工審核。

金鑰只能發起受治理的請求。金鑰不具備審批權限。職責分離原則要求每項審批均須由人工成員執行，腳本程式無法取代此判斷。若提款請求政策要求兩項審批，由金鑰發起的提款須等待兩位成員審批，與成員發起的請求一致。

請在自動化流程中考慮此非同步特性：API 呼叫成功僅代表請求已建立，並非資金已劃撥。請追蹤請求直至完成，並注意現有限制：待處理的請求不會預留資金。若審核期間餘額發生變動，已審批的請求可能失敗，須重新提交。請參閱 審批完成前保持資金充足。

金鑰亦無法進入任何管理工作流程。管理團隊存取權限、API 金鑰、帳戶、地址（發起地址請求除外）及政策，均為成員專屬功能。

金鑰的管理方式

建立、編輯及撤銷 API 金鑰屬受治理操作，須透過專屬的「管理 API 金鑰」工作流程執行，與「管理團隊及存取權限」工作流程各自獨立。此分離設計有兩項重要意義：

• 管理員各有分工。您可授權運營工程師管理金鑰，而無需賦予其變更成員存取權限的能力，反之亦然。
• 政策各自獨立。金鑰管理可設有獨立的審批要求。許多 Organization 要求對建立或修改金鑰進行獨立審批（新憑證即代表一種新的帳戶存取途徑），同時保持撤銷操作的靈活性。

1. 請前往 API 金鑰，然後選擇 建立金鑰。
2. 請以金鑰的用途為其命名，說明它所服務的系統及功能，確保在審查和安全事件中一目了然。
3. 請選擇金鑰的權限。
4. 請選擇金鑰所操作的帳戶。所選權限將統一應用於所有帳戶。
5. 請設定安全設定：到期日、IP 限制及隨機數視窗。
6. 請審閱並確認。若「管理 API 金鑰」政策要求審批，請求將等待所需審批完成後方可發出金鑰。

編輯金鑰的權限或帳戶，以及撤銷金鑰，均須遵循相同的治理流程。

此 API 呼叫已建立提款請求，目前正依提款請求政策等待審批。請前往「請求」頁面查看，該請求將以金鑰為發起方顯示，並等待所需成員審批。這正是治理模型的預期運作方式：由自動化系統發起請求，由人工審批。

若請求已獲批准但資金仍未移動，請確認完成時來源帳戶的餘額是否足夠——待審請求不會預留資金，審核期間的帳戶操作可能導致已批准的請求失敗。請在餘額補足後重新提交。

出錯的帳戶不在金鑰的帳戶對應範圍內。金鑰僅對其所選帳戶生效。請編輯金鑰以新增該帳戶，但請注意金鑰的完整權限將統一套用至所有帳戶，不支援按帳戶單獨設定。若權限範圍過廣，建議為該帳戶單獨建立一個新金鑰。

單一金鑰無法針對不同帳戶設定不同權限。請建立兩個金鑰：一個交易金鑰對應帳戶 A，一個唯讀金鑰對應帳戶 B。權限範圍較窄的金鑰亦更易於審計，撤銷時風險更低。

Manage API Keys 工作流程可能需要審批，該請求仍在待處理狀態。金鑰須在收集所需審批後方可簽發，其密鑰亦於同一時間顯示。請在「請求」頁面查看該請求的狀態。

不可以。審批必須由真人成員執行。這是系統規則，並非可設定的政策。正是這項規則，確保在自動化流程發起資金操作時，多方審批機制具有實質意義。