通用說明
WebSocket 通用格式
WebSocket 請求統一使用 JSON。常見欄位：
訂閱示例：
event 改為 unsubscribe。服務端資料推送通常使用 event: "update"。
HTTP 通用格式
- 所有讀操作使用
GET方法，只接收 URL / Query 參數，不讀取請求體。 DELETE用於刪除指定資源，例如撤銷訂單；由於DELETE不讀取請求體，複雜刪除操作會透過POST並在請求體中傳參實現。- 更新操作根據介面使用
POST、PUT或PATCH，參數可能位於 Query 或 Request Body，具體以介面頁面為準。 - 請求成功回傳
2xx；401通常表示認證失敗；其他4xx表示請求參數、格式或權限存在問題；5xx表示服務端處理異常。
時間
除介面另有說明外，時間相關欄位統一使用 Unix 時間戳，單位為秒。不同介面回傳的資料類型可能不同，例如：Timestamp 使用 Unix 秒級時間戳，並需要滿足服務端允許的時間偏差。
網關入出站時間
API 響應 Header 會回傳網關接收請求和發出響應的時間，可用於分析請求在網關及服務端的耗時：
示例：
分頁
清單介面根據介面類型使用以下一種或多種方式分頁。limit + offset
last_id
部分歷史介面支援使用上一頁最後一條記錄的 ID 作為下一頁起點。具體欄位名稱和是否已廢棄，以介面頁面為準。from + to
時間範圍介面通常使用：
部分介面會同時配合
limit、offset 使用。
限頻規則
目前 PerpDEX 交易類請求按以下規則控制頻率：- 單筆下單、批量下單、改單、撤單、批量撤單等交易請求：合計最高
100 req/s。 - 其他介面目前不設定相同的交易請求頻率限制，但仍應避免無意義的高頻輪詢。
- 單 IP 最大連接數：
300。
429。客戶端應根據狀態碼進行退避重試，避免立即連續重放請求。
回傳格式
介面預設使用 JSON 回傳資料。 請求成功時根據介面定義回傳對象、數組或空結果；請求失敗時通常回傳非2xx 狀態碼，並在 JSON 中提供錯誤類型和錯誤說明。
成功示例：
資料類型
常見資料類型：價格、數量、保證金等金融數值建議保持字串或使用高精度 Decimal 處理，避免直接使用二進制浮點數造成精度損失。
Trace ID
API 響應 Header 中會攜帶：X-Trace-ID 與請求 URI、HTTP 狀態碼、請求時間一起保留。
Self-Trade Prevention（STP）
STP 用於防止同一 STP Group 內的帳戶訂單相互成交。STP 策略
使用 STP 前，帳戶需要加入 STP Group。屬於同一 Group 的訂單發生潛在自成交時，系統會根據 Taker 訂單的
stp_act 決定取消哪一側訂單。
如果帳戶已加入 STP Group，但下單時沒有指定 stp_act，預設按 cn 處理。帳戶未加入 STP Group 時傳入 STP 參數，服務端可能拒絕該請求。
下單相關欄位
以建立訂單介面為例：
響應中可能包含：
異常處理
所有異常請求都會回傳非2xx HTTP 狀態碼，並通常使用 JSON 描述錯誤。
標準錯誤結構示例：
label：穩定的錯誤類型標識，程式應優先使用該欄位判斷錯誤類型。message或detail：用於說明具體錯誤原因，適合展示和排查，不建議依賴完整文本做程式判斷。
- 先判斷 HTTP 狀態碼。
- 再讀取
label識別業務錯誤類型。 - 使用
message/detail輔助排查。 - 保存
X-Trace-ID便於定位請求鏈路。