跳转到主要内容

通用说明

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 参数,服务端可能拒绝该请求。

下单相关字段

以创建订单接口为例:
请求可包含: 响应中可能包含:
如果当前 DexBuilder PerpDEX 部署未启用 STP,应以实际交易系统能力为准,并避免依赖 stp_act、stp_id 或 finish_as=stp 进行核心业务判断。

异常处理

所有异常请求都会返回非 2xx HTTP 状态码,并通常使用 JSON 描述错误。 标准错误结构示例:
  • label:稳定的错误类型标识,程序应优先使用该字段判断错误类型。
  • message 或 detail:用于说明具体错误原因,适合展示和排查,不建议依赖完整文本做程序判断。
客户端建议按以下顺序处理异常:
  1. 先判断 HTTP 状态码。
  2. 再读取 label 识别业务错误类型。
  3. 使用 message / detail 辅助排查。
  4. 保存 X-Trace-ID 便于定位请求链路。

异常 Label 列表

请求参数与格式

认证与权限

PerpDEX 业务错误

服务端错误

业务错误处理应优先依赖 label,不要依赖完整的 message 文本。排查问题时不要提供 API Secret、私钥或其他敏感认证信息。