示例使用预生产 REST API
https://api.qfex.io 和交易 WebSocket wss://trade.qfex.io。实际集成请使用 QFEX 为您提供的环境 URL 和凭据。
本流程返回 API 密钥。钱包会话认证返回访问令牌和刷新令牌;OAuth则使用应用授权。
开始之前
开发者需要:- 一个拥有有效 Builder Code 的 QFEX 账户。
- 该账户的用户名,用于生成密钥标签。
- 由 Builder Code 所属账户拥有的现有 API 公开密钥和私密密钥。
- 在该 Builder API 密钥上启用
register_user权限。请联系 support@qfex.com申请启用;subaccount_ops不提供注册权限。
1. 获取钱包消息
传入用户的以太坊地址及您的 Builder Code UUID:200 OK 响应包含 message 字符串。例如:
message,不得修改。域名和 URI 由 QFEX 按环境配置,不要替换为您的应用 URL,也不要翻译签名消息。
接口会生成新的 nonce 及十分钟有效期。若签名或提交耗时过长,请重新获取消息。返回消息并不代表开发者代码存在或有效;这些检查在注册时执行。
2. 请求钱包签名
使用用户选定的 EIP-1193 提供者。Rabby 支持此接口。安装多个钱包时,请使用 EIP-6963 发现机制,不要假设window.ethereum 就是用户选定的钱包。
{ message, signature } 发送至后端。不要在消息字符串中添加 Wallet signature 字样或签名本身。
3. 注册用户并创建交易密钥
后端使用开发者凭据和以下四个 HMAC 请求头调用POST /builder/web3/api-key:
HTTP nonce 与钱包消息中的 nonce 相互独立。每次请求或重试都必须生成新的 HMAC 请求头。
Node.js 后端示例:
message 和 signature。QFEX 从已认证的开发者账户解析 Builder Code,并要求签名消息明确授权同一个代码。此请求应使用开发者自己的 API 密钥,而非终端用户交易密钥。
钱包签名必须与消息中的地址一致。消息必须在十分钟内签发,不能过期或使用未来的签发时间,且域名与 URI 必须被 QFEX Auth 接受。
首次出现的钱包通过钱包注册创建 QFEX 用户和主账户;已有钱包恢复原用户。账户创建完成后,才能签发密钥。
响应与密钥权限
成功创建返回201 Created,并带有 Cache-Control: no-store:
该密钥授予主账户的订单执行权限,以及订单、持仓和余额读取权限。其
view_balance 权限还允许调用资金服务上的 GET /address 和 GET /withdrawal-addresses。通过 POST /builder/web3/api-key 签发或替换的密钥,还可以调用 POST /withdraw,向用户在所请求网络上已登记的地址提现。此权限无法在开发者设置中选择,且要求对所选账户拥有所有者访问权限。
deposit_withdraw 仍保持禁用:该密钥不能轮换充值地址、管理银行账户或提取美元。子账户不在其访问范围内。本接口不返回访问令牌或刷新令牌。资金服务 URL、认证请求头及示例见程序化出入金。
请安全保存返回的凭据,避免记录或缓存。它们用于以钱包用户身份认证后续交易请求,不替代开发者自身的注册凭据。
密钥替换与交易归因
密钥标签为builder- 加开发者账户用户名,例如 builder-alice。对同一用户、同一 Builder 标签再次签发密钥,会删除之前的密钥及其保存的私密部分。替换失败会回滚并保留旧密钥。其他用户和其他 Builder 标签的密钥不受影响。
密钥不会在使用后立即自动撤销。成功替换后,旧密钥无法再用于后续认证。以 builder- 或 managed 开头的密钥标签不显示在用户普通 API 密钥列表中。
使用返回的用户密钥执行 HMAC 交易 WebSocket 身份认证,并在 params.builder_code 中包含您的 Builder Code UUID。仅凭密钥标签不会归因订单。每次重连都必须再次附加代码。
错误
从浏览器直接调用时,API 必须通过 CORS 允许您的来源及请求头。底层 Auth 交换由后端处理;此 Builder 流程不要求前端调用
/auth/v1/token?grant_type=web3,也不要求前端持有 Auth 客户端密钥。