Bitget API Key 安全設定完整教學
sub-account 隔離、IP 白名單、Passphrase 三個關鍵

你要把 TradingView 訊號、或某個交易機器人接到 Bitget 自動下單，第一件事就是建一把 API key——這也是 Bitget API key security 這件事真正被決定的一步。90% 的人在這一步權限給太寬——照著網路上 Binance 版教學隨手勾一勾，忘了 Bitget 多了一個 Passphrase、少了一個「Read」獨立勾選項，還有一整套 sub-account 可以自己管 API 的機制沒有用到。這篇把 Bitget 官方 API 文件、加上我們自己 跨 10 家交易所的權限檢查清單已經查證過的部分，整理成 Bitget 專用版，只講會影響你風險大小的三件事：權限最小化、IP 白名單、以及那個很多人沒開的 sub-account 隔離。

這篇不比較 Bitget 跟其他家的資安誰做得好——那需要跨交易所實測與內部制度審計，我們沒做過，這篇也不會做。這篇不教你怎麼在 Bitget 上做交易策略，只講 API key 這一層。範圍縮在這裡，是因為只要這一層設對了，就算某個下游工具將來被駭，你的資金也搬不走；設錯了，後面所有防護都變成裝飾。

Bitget 的 API key 權限模型：兩套 API、兩種介面

Bitget 目前並存兩套 API：Classic API（現貨與合約各自獨立的舊介面）與 UTA（Unified Trading Account，統一交易帳戶）——後者是 Bitget 官方文件標「🔥 Recommended」的新一代介面。權限模型在兩套裡稍有不同，UI 上實際能勾的選項也隨帳戶模式而變。這一點跟 Binance／BingX 只有一組固定權限清單不同，是Bitget 特有的複雜度。

還有一個 Bitget 跟 Binance／BingX 不一樣的地方——Bitget 的 API 認證要三把 key，不是兩把：ACCESS-KEY、Secret Key、加上一個 Passphrase。這個 Passphrase 是你建 key 當下自己設的密碼，官方文件寫得很直白：「if the Passphrase is forgotten, it cannot be retrieved and the APIKey needs to be re-created」——忘了就得重建一把 key。這一點跟 OKX 的做法一樣，跟 Binance／BingX 只有 API Key + Secret 兩把不同。實務意義是：你的三把 key 任何一把外洩，都可能造成資產損失——Bitget 官方風險提示的原文是「The leakage of any one of these three keys may cause the loss of your assets」——所以 Passphrase 也要當祕密看待，跟 API Key／Secret 一起存進密碼管理工具。

三個必做設定：關 Withdraw、綁 IP、用 sub-account

設定一：不要勾 Withdraw 權限

這一條的重要性在於它決定了 key 外洩時的損失規模，其他兩條決定的是外洩機率。就算你把 IP 白名單設得再嚴、Passphrase 藏得再深，只要哪天 key 從別的地方漏出去——電腦中毒、SaaS 平台被駭、自己手滑 push 到公開 repo——Withdraw 有沒有勾，決定的是駭客能不能直接把錢搬走。

Bitget 在 key 層級可以把交易跟提幣完全分開——這一點我們的跨交易所檢查清單裡逐條對照過，Bitget 屬於「可以分開」的 9 家之一（Gate.io 是唯一例外）。所以這件事的難度不是技術限制，是你有沒有記得不勾而已。Bitget 對 Withdraw 權限有一個額外要求——只要你勾了 Withdraw，就會被要求綁 IP 白名單，這是強制的。其他家（Binance、BingX）也一樣有這個規則，是這個小圈子裡的業界共識。

設定二：綁 IP 白名單

Bitget 官方 UTA 快速入門文件的原文是「For security reasons, it is strongly recommended that you bind an IP address when creating the API Key」——「強烈建議」，不是強制（除非你勾了 Withdraw）。這是 Bitget 跟其他家不同的地方：Binance、BingX 對「沒綁 IP 的 key」都加了強制的自動刪除規則（30 天／14 天），Bitget 官方文件目前沒有寫這種到期機制。這個差別對你的實務意義是：Bitget不會幫你把懶得綁 IP 的 key 定期清掉，你自己得主動綁，不然它就會一直放著。

你自己架的 VPS 通常就 1 個固定 IP，用 SaaS 平台的話對方會給你一組固定出口 IP（TVSBot 給的是一組，其他工具數量不一，接工具之前先問清楚）。IP 白名單的欄位在 Bitget 建 key 的介面裡是明確存在的一個輸入框，填了之後只有來自這些 IP 的請求會被接受。

設定三：把跑機器人的 key 放在 sub-account——這是 Bitget 的差異化做法

這一條是這篇跟 Binance 版最大的不同，也是 Bitget 官方文件裡真的做得比較細的地方——Bitget 的 sub-account 可以自己建、自己管 API key，不需要主帳號幫忙操作。這一節值得單獨拆一個 H2 講清楚。

sub-account 隔離：Bitget 官方支援、但預設是關的

Bitget 官方 UTA 文件把這件事寫得很清楚——「Sub-accounts (virtual sub-accounts and standard sub-accounts) can create and manage their own API Keys independently, without requiring the main account to operate on their behalf」。翻成白話：你可以在主帳號底下建一個 sub-account，把資金分過去，讓那個 sub-account 自己建 API key 跑機器人——主帳號完全不需要建任何 key。這帶來的好處是隔離，如果那把 sub-account 的 key 出問題（外洩、策略失控、單子亂下），影響範圍限縮在該 sub-account 的資金，主帳號其他資產不會被波及。

但這件事有個關鍵前提是很多人漏掉的——這個功能預設是關閉的。Bitget 官方 UTA 文件用一整段警告：「Prerequisite: The main account must enable the API Key Management permission for the sub-account. This setting is disabled by default. The main account can configure it under sub-account permission settings」。所以你不是「建了 sub-account 就能用」，而是要主動去主帳號的 sub-account 權限設定裡，把 API Key Management 這個權限打開，之後 sub-account 才能自己建 key。開啟之後 sub-account 可以做的事，官方列了四件：

• Create API Key（建 key）
• View API Key（查看 key 資訊）
• Edit API Key permissions（改權限）
• Delete API Key（刪除 key）

同一節官方另外補了一句：「The main account retains full control and can view, edit, or delete any sub-account's API Keys at any time」——主帳號隨時可以看、改、刪 sub-account 的所有 key。這件事的實務意義是：你把跑機器人的權限下放給 sub-account，並沒有失去對它的控制權——sub-account 是操作單位，主帳號永遠是 root。

這張比較表不是要判 Bitget 的做法比較好——兩家的思路不一樣，各有適合的情境。Bitget 的「sub-account 自己管 API」對不同人跑不同機器人的團隊比較友善（例如你跟合作夥伴各管一個策略），主帳號不用當中轉站。Binance 那種主帳號一手代管的做法，對單人單機器人的散戶反而是簡單的——反正一切都在你手上。挑哪個，看你實際場景。

Bitget 沒有明文到期機制，意味著什麼

對比其他家的做法你就能看出這個差異的分量——Binance 對沒綁 IP 的 key 是 30 天閒置刪除，BingX 是 14 天，OKX 是 14 天。Bitget 官方 UTA 快速入門、以及 Classic API 文件裡，都查不到針對「沒綁 IP 的 key」或「閒置多久」的自動到期規則。這件事在我們的跨 10 家交易所檢查清單裡也是同樣的結論。

這個差異對你的實務意義有兩層：好處是你不用擔心機器人某天早上因為 key 到期靜默斷線——Bitget 不會這樣做。壞處是失效的 key（例如你早就不用某個工具了、但忘了刪 key）會一直躺在你的 API 管理頁面裡，多一把懸在那裡不會被清掉的攻擊面。這一條你得靠自己：定期回 Bitget 的 API 管理頁面核對，把不用的 key 主動刪掉——這件事沒有交易所會幫你做。

建 Bitget API Key 的實際流程

Bitget 的 UI 會偶爾改版，這裡不寫具體像素位置的按鈕動線——只給你必經的步驟骨架。實際設定時請以 Bitget 帳戶頁當下顯示為準。假設你要走「sub-account 跑機器人」這條路，流程比單建一把主帳號 key 多兩步，但整個 workflow 只做一次，之後就穩了。

【第一次設定：把 sub-account 打開】
        1. 登入 Bitget → 右上角頭像 → Sub-Accounts（子帳戶管理）
        2. Create Sub-Account → 填 sub-account 名稱、Email、密碼
        3. 在該 sub-account 的權限設定裡，勾選 API Key Management
           （官方文件明講：這一項預設是關的，你要主動開）
        4. 把主帳號要分給機器人的資金，透過 Transfer 移到 sub-account

        【建 API key：用 sub-account 身份】
        5. 登出主帳號 → 用 sub-account 帳號登入（或用 sub-account 切換功能）
        6. 右上角 → API Management → Create API Key
        7. 填 Label（例如：tvsbot-prod、grid-bot-01）
        8. 設定 Passphrase（自己想一組 8~32 字元的密碼，忘了得重建 key）
        9. 完成 2FA 驗證
        10. 拿到三把 key：API Key、Secret Key、Passphrase
            （Secret Key 只顯示一次，立刻複製）

        【設權限：只勾要的、不勾提幣】
        11. 點該 key 進入 Edit：
            - 勾選需要的 Trade 類別（Spot 或 Futures，依你策略）
            - 不要勾 Withdraw
            - 不要勾 Transfer（除非你的機器人需要自動調度保證金）
            - 填入 IP 白名單（Bitget 官方「strongly recommended」，你就照做）
        12. Save changes

Secret Key 只會顯示一次——這是所有交易所的共通規則。Bitget 因為多了 Passphrase，一起要存好——這三把 key 任何一把外洩，官方都寫得明白會導致資產損失。密碼管理工具（1Password、Bitwarden、macOS Keychain）都可以；貼進純文字檔案、Slack、Email 是不好的習慣，一次養成一次痛。

怎麼挑串接 Bitget 的自動化工具

Bitget 目前是我們自己 TradingView Webhook 支援交易所整理裡列為「有官方 REST／WebSocket API 可對接、能接自動下單」的名單成員——這代表市面上不少工具都聲稱能接。挑工具時值得問清楚三件事：

• 它會不會要求你把 key 開 Withdraw 權限？會的話直接跳過這個工具——現貨與合約下單這件事，技術上永遠不需要提幣權限，會要求就是架構有問題。
• 它給你的固定 IP 有幾個？多數 SaaS 是 1～3 個，你都塞得進 Bitget 的 IP 白名單欄位；有些工具是動態出口 IP（每次呼叫可能不一樣），這種你就沒辦法綁 IP 白名單，得回頭權衡是不是可以接受。
• 你的三把 key（尤其是 Passphrase）存在他們那邊的方式是什麼？明文存在資料庫是警訊；加密儲存而且加密主金鑰跟資料庫實體分開存放，是值得問清楚的基本門檻。

就我們自己來說：TVSBot 用 Fernet（AES-128-CBC + HMAC-SHA256）加密儲存你的三把 key，加密主金鑰只存在環境變數、跟資料庫本身分開存放；每一筆下單都直接用你自己的 key 呼叫 Bitget API，我們不會持有你的資金；設定文件建議使用者只開 Trade 權限、並提供一組固定出口 IP 讓你填進 Bitget 白名單，並強烈建議把 key 建在 sub-account 而不是主帳號。同一份 checklist 適用於任何非託管工具，不只是 TVSBot——所以就算你最後選了別家，這一節的清單也用得上。

誠實的一段：這篇文章沒解決的問題

即便你把上面三個設定全部做好，還有一些風險是這篇教學無法幫你消除的，寫在這裡是為了讓你有正確的預期：

第一，交易所本身被駭這件事沒有 API key 層級的防禦可以擋——你的資產放在 Bitget 上，就是承擔 Bitget 這個平台的營運風險。這一層要靠交易所的 Proof of Reserves、保險基金、以及你自己分散持有到多家平台或冷錢包來處理，不是靠 key 怎麼設定。

第二，你自己的策略把錢虧掉，跟 API key 安全無關——這篇沒有討論任何策略層面的風險。任何自動化交易架構都不會替你保證賺到錢，這件事永遠成立；即使是最保守的 grid bot、資費套利，遇到極端行情都會虧損。策略層面的風險評估請看我們的 Kelly 公式與部位大小、ATR 波動率動態調整部位兩篇。

第三，我們沒能對 Bitget 做完整的內部制度審計——本文所有關於 Bitget 官方規則的敘述，都是根據可公開查證的文件與帳戶頁面內容整理出來的，查證日期 2026 年 7 月。交易所政策會在沒有太多預告的情況下變動，實際設定前建議自己再去 Bitget 官方 API 文件頁面確認一次現行規則。

常見問題