Bybit API教程：如何連接並開始自動交易？

了解Bybit API認證

1. Bybit 需要從用戶帳戶儀表板的 API 管理部分下生成 API 密鑰。這些密鑰由 API 密鑰和秘密密鑰組成，兩者對於簽署請求都至關重要。

2. 密鑰絕不能暴露在客戶端代碼或公共存儲庫中。用於為每個請求生成HMAC-SHA256簽名，以驗證身份並防止篡改。

3. 用戶必須在密鑰創建過程中分配精確的權限，例如“訂單”、“錢包”或“合同”訪問權限，並在生產環境中操作時限制 IP 地址。

4. 時間同步是強制性的。請求被拒絕並出現錯誤代碼 10004 表示時間戳不匹配；系統必須將相對於 Bybit 服務器時間的時鐘漂移保持在 30 秒以內。

5. 所有端點都需要包含公鑰的 X-BAPI-API-KEY 標頭和包含從串聯參數和秘密派生的 Base64 編碼簽名的 X-BAPI-SIGN 標頭。

設置 REST API 集成

1. 開發人員通常使用 Python 和requests庫來構建經過身份驗證的 GET/POST 調用。一個典型的示例包括通過 /v5/account/wallet-balance 端點獲取錢包餘額。

2. 構建簽名字符串時，查詢參數必須先按字母順序排序，然後再進行哈希處理。 Nonce 值必須在連續請求中單調增加，以避免重放攻擊。

3. 每個端點的速率限制各不相同：公共端點每分鐘最多允許 60 個請求，而私有端點的上限為每分鐘 120 個請求，除非通過 Bybit 的機構層進行升級。

4. 錯誤處理必須解析 JSON 響應以獲取狀態代碼，例如 10001（無效 API 密鑰）、10002（無效簽名）或 110001（餘量不足），以觸發適當的回退邏輯。

5. 會話重用提高了性能——通過urllib3的PoolManager的持久連接減少了高頻訂單提交期間的TCP握手開銷。

WebSocket 實時數據流

1. Bybit支持WebSocket v5來獲取實時市場數據、交易執行更新和倉位變化。使用與 REST 相同的 API 密鑰和簽名方法通過單個身份驗證幀啟動連接。

2. 訂閱orderbook.1.BTCUSDT或trade.BTCUSDT等主題需要發送帶有 op: 'subscribe' 和 args: ['topic.name'] 的 JSON 負載。

3. 必須每 20 秒發送一次心跳 ping，以保持連接穩定性。如果在超時窗口內未能響應，則會觸發強制斷開連接和重新連接序列。

4. 消息壓縮默認處於禁用狀態，但可以在 WebSocket 握手期間通過 permessage-deflate 擴展協商來啟用，以實現帶寬敏感的部署。

5. 訂單簿快照首先作為全深度快照到達，然後是增量更新。客戶端必須正確應用這些增量，以避免狀態不同步和錯誤定價。

構建基本的自動交易機器人

1. 一個最小的工作機器人首先初始化憑據，建立用於價格反饋的 WebSocket 連接，並設置用於下單的 REST 會話。

2. 策略邏輯（例如檢測移動平均線交叉）在從 WebSocket 交易流重建或通過 REST /v5/market/kline 獲取的逐筆報價級別 OHLCV 數據上運行。

3. 訂單執行使用 POST /v5/order/create，並嚴格驗證邊線（買入/賣出）、訂單類型（市價/限價）和數量字段。數量格式無效返回錯誤 30089。

4. 風險控制包括在提交前檢查可用保證金、驗證未結訂單數量限制以及根據權益百分比強制執行最大頭寸規模。

5. 日誌記錄必須捕獲原始請求/響應有效負載、時間戳和執行延遲指標，以幫助調試延遲峰值或意外填充。

常見問題解答

問：測試網和主網可以使用相同的 API 密鑰嗎？答：不需要。測試網和主網需要單獨生成 API 密鑰。在一種環境中創建的密鑰在另一種環境中不起作用。

問：如果我的機器人發送重複的訂單 ID 會怎樣？答：Bybit 在 24 小時窗口內拒絕重複的 clOrdID 值，錯誤代碼為 110012，防止意外重複提交。

問：有沒有辦法檢索超過 7 天的歷史交易記錄？答：REST /v5/execution/list 僅返回過去一周的記錄。對於擴展檔案，用戶必須在實時操作期間在自己的基礎設施上啟用交易日誌記錄。

問：現貨和衍生品 API 是否共享相同的身份驗證流程？答：是的。兩者都使用相同的 HMAC-SHA256 簽名邏輯和標頭結構，儘管端點路徑和所需參數在產品類型之間存在顯著差異。