REST行情与交易接口
最近更新: 2024-12-17
API 基本信息
- 本篇列出接口的 base URL 有:
- 上述列表的最后4个接口 (
api1
-api4
) 会提供更好的性能,但其稳定性略为逊色。因此,请务必使用最适合的URL。 - 所有接口的响应都是 JSON 格式。
- 响应中如有数组,数组元素以时间升序排列,越早的数据越提前。
- JSON 响应中的所有时间和时间戳相关字段均以毫秒为默认单位。要以微秒为单位接收信息,请添加报文头
X-MBX-TIME-UNIT:MICROSECOND
或X-MBX-TIME-UNIT:microsecond
。 - 时间戳参数(例如
startTime
、endTime
、timestamp
)可以以毫秒或微秒为单位传递。 - 对于仅发送公开市场数据的 API,您可以使用接口的 base URL https://data-api.binance.vision 。请参考 Market Data Only_CN 页面。
HTTP 返回代码
- HTTP
4XX
错误码用于指示错误的请求内容、行为、格式。问题在于请求者。 - HTTP
403
错误码表示违反WAF限制(Web应用程序防火墙)。 - HTTP
409
错误码表示重新下单(cancelReplace)的请求部分成功。(比如取消订单失败,但是下单成功了) - HTTP
429
错误码表示警告访问频次超限,即将被封IP。 - HTTP
418
表示收到429后继续访问,于是被封了。 - HTTP
5XX
错误码用于指示Binance服务侧的问题。
接口错误代码
- 每个接口都有可能抛出异常,异常响应格式如下:
{
"code": -1121,
"msg": "Invalid symbol."
}
- 具体的错误码及其解释在错误代码汇总
接口的基本信息
GET
方法的接口, 参数必须在query string
中发送。POST
,PUT
, 和DELETE
方法的接口,参数可以在内容形式为application/x-www-form-urlencoded
的query string
中发送,也可以在request body
中发送。 如果你喜欢,也可以混合这两种方式发送参数。- 对参数的顺序不做要求。
- 但如果同一个参数名在
query string
和request body
中都有,query string
中的会被优先采用。
访问限制
访问限制基本信息
- 以下是
intervalLetter
作为头 部值:- SECOND => S
- MINUTE => M
- HOUR => H
- DAY => D
- 在
/api/v3/exchangeInfo
接口中rateLimits
数组里包含有REST接口(不限于本篇的REST接口)的访问限制。包括带权重的访问频次限制、下单速率限制。参考 枚举定义 中有关有限制类型的进一步说明。 - 当您超出请求速率限制时,请求会失败并返回 HTTP 状态代码 429。
IP 访问限制
- 每个请求将包含一个
X-MBX-USED-WEIGHT-(intervalNum)(intervalLetter)
的头,其中包含当前IP所有请求的已使用权重。 - 每一个接口均有一个相应的权重(weight),有的接口根据参数不同可能拥有不同的权重。越消耗资源的接口权重就会越大。
- 收到429时,您有责任停止发送请求,不得滥用API。
- 收到429后仍然继续违反访问限制,会被封禁IP,并收到418错误码
- 频繁违反限制,封禁时间会逐渐延长,从最短2分钟到最长3天.
Retry-After
的头会与带有418或429的响应发送,并且会给出以秒为单位的等待时长(如果是429)以防止禁令,或者如果是418,直到禁令结束。- 访问限制是基于IP的,而不是API Key
未成交订单计数
- 每个成功的订单响应都将包含一个
X-MBX-ORDER-COUNT-(intervalNum)(intervalLetter)
报文头,用于标识您在该时间间隔内下了多少订单。
如果您想要对此进行监控,请参阅GET api/v3/rateLimit/order
。 - 被拒绝/不成功的订单不保证在响应中有
X-MBX-ORDER-COUNT-**
报文头。 - 如果超过此值,您将收到一个 429 错误,而且不带
Retry-After
报文头。 - 请注意,如果您的订单一直顺利完成交易,您可以通过 API 持续下订单。更多信息,请参见现货未成交订单计数规则。
- 未成交订单数量是按照每个账户来统计的。
数据来源
- 因为API系统是异步的, 所以返回的数据有延时很正常, 也在预期之中。
- 在每个接口中,都列出了其数据的来源,可以用于理解数据的时效性。
系统一共有3个数据来源,按照更新速度的先后排序。排在前面的数据最新,在后面就有可能存在延迟。
- 撮合引擎 - 表示数据来源于撮合引擎
- 缓存 - 表示数据来源于内部或者外部的缓存
- 数据库 - 表示数据直接来源于数据库
有些接口有不止一个数据源, 比如 缓存 => 数据库
, 这表示接口会先从第一个数据源检查,如果没有数据,则检查下一个数据源。
接口鉴权类型
- 每个接口都有自己的鉴权类型,鉴权类型决定了访问时应当进行何种鉴权。
- 鉴权类型会在本文档中各个接口名称旁声明,如果没有特殊声明即默认为
NONE
。 - 如果需要 API-keys,应当在HTTP头中以
X-MBX-APIKEY
字段传递。 - API-keys 与 secret-keys 是大小写敏感的。
- API-keys可以被配置为只拥有访问一些接口的权限。
例如, 一个 API-key 仅可用于发送交易指令, 而另一个 API-key 则可访问除交易指令外的所有路径。 - 默认 API-keys 可访问所有鉴权路径.
鉴权类型 | 描述 |
---|---|
NONE | 不需要鉴权的接口 |
TRADE | 需要有效的API-KEY和签名 |
USER_DATA | 需要有效的API-KEY和签名 |
USER_STREAM | 需要有效的API-KEY |
MARKET_DATA | 需要有效的API-KEY |
TRADE
和USER_DATA
接口是 签名(SIGNED)接口.
需要签名的接口 (TRADE 与 USER_DATA)
- 调用
SIGNED
接口时,除了接口本身所需的参数外,还需要在query string
或request body
中传递signature
, 即签名参数。 签名
大小写不敏感.- 请参考下面 签名示例 以了解具体如何做计算签名。
时间同步安全
-
签名接口均需要传递
timestamp
参数,其值应当是请求发送时刻的unix时间戳(毫秒)。 -
服务器收到请求时会判断请求中的时间戳,如果是5000毫秒之前发出的,则请求会被认为无效。这个时间空窗值可以通过发送可选参数
recvWindow
来定义。 -
逻辑伪代码:
if (timestamp < (serverTime + 1000) && (serverTime - timestamp) <= recvWindow) {
// process request
} else {
// reject request
}
关于交易时效性
互联网状况并不100%可靠,不可完全依赖, 因此你的程序本地到币安服务器的时延会有抖动.
这是我们设置recvWindow
的目的所在,如果你从事高频交易,对交易时效性有较高的要求,可以灵活设置recvWindow
以达到你的要求。
不推荐使用5秒以上的recvWindow。最大值不能超过60秒!
POST /api/v3/order 的示例
HMAC Keys
以下是在linux bash环境下使用 echo
,openssl
和curl
工具实现的一个调用接口下单的示例
apikey、secret仅供示范
Key | Value |
---|---|
apiKey | vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A |
secretKey | NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j |
参数 | 取值 |
---|---|
symbol | LTCBTC |
side | BUY |
type | LIMIT |
timeInForce | GTC |
quantity | 1 |
price | 0.1 |
recvWindow | 5000 |
timestamp | 1499827319559 |
示例 1: 所有参数通 过 query string 发送
-
queryString: symbol=LTCBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000×tamp=1499827319559
-
HMAC SHA256 签名:
[linux]$ echo -n "symbol=LTCBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000×tamp=1499827319559" | openssl dgst -sha256 -hmac "NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j"
(stdin)= c8db56825ae71d6d79447849e617115f4a920fa2acdcab2b053c4b2838bd6b71 -
curl 调用:
(HMAC SHA256)
[linux]$ curl -H "X-MBX-APIKEY: vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A" -X POST 'https://api.binance.com/api/v3/order?symbol=LTCBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000×tamp=1499827319559&signature=c8db56825ae71d6d79447849e617115f4a920fa2acdcab2b053c4b2838bd6b71'
示例 2: 所有参数通过 request body 发送
-
requestBody: symbol=LTCBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000×tamp=1499827319559
-
HMAC SHA256 签名:
[linux]$ echo -n "symbol=LTCBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000×tamp=1499827319559" | openssl dgst -sha256 -hmac "NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j"
(stdin)= c8db56825ae71d6d79447849e617115f4a920fa2acdcab2b053c4b2838bd6b71 -
curl 调用:
(HMAC SHA256)
[linux]$ curl -H "X-MBX-APIKEY: vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A" -X POST 'https://api.binance.com/api/v3/order' -d 'symbol=LTCBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000×tamp=1499827319559&signature=c8db56825ae71d6d79447849e617115f4a920fa2acdcab2b053c4b2838bd6b71'
示例 3: 混合使用 query string 与 request body
-
queryString: symbol=LTCBTC&side=BUY&type=LIMIT&timeInForce=GTC
-
requestBody: quantity=1&price=0.1&recvWindow=5000×tamp=1499827319559
-
HMAC SHA256 签名:
[linux]$ echo -n "symbol=LTCBTC&side=BUY&type=LIMIT&timeInForce=GTCquantity=1&price=0.1&recvWindow=5000×tamp=1499827319559" | openssl dgst -sha256 -hmac "NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j"
(stdin)= 0fd168b8ddb4876a0358a8d14d0c9f3da0e9b20c5d52b2a00fcf7d1c602f9a77 -
curl 调用:
(HMAC SHA256)
[linux]$ curl -H "X-MBX-APIKEY: vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A" -X POST 'https://api.binance.com/api/v3/order?symbol=LTCBTC&side=BUY&type=LIMIT&timeInForce=GTC' -d 'quantity=1&price=0.1&recvWindow=5000×tamp=1499827319559&signature=0fd168b8ddb4876a0358a8d14d0c9f3da0e9b20c5d52b2a00fcf7d1c602f9a77'
Note that the signature is different in example 3. There is no & between "GTC" and "quantity=1".
RSA Keys
- 这将逐步介绍如何通过有效的签名发送 payload。
- 我们接受
PKCS#8
格式的RSA密钥。 - 要获取 API Key,您需要在您的账户上上传您的 RSA Public Key。
- 对于这个例子,Private Key 将被引用为
test-prv-key.pem
。
Key | Value |
---|---|
apiKey | CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ |
参数 | 取值 |
---|---|
symbol | BTCUSDT |
side | SELL |
type | LIMIT |
timeInForce | GTC |
quantity | 1 |
price | 0.2 |
timestamp | 1668481559918 |
recvWindow | 5000 |
第一步: Payload
将参数列表排列成一个 string。 用 &
分隔每个参数。对于上述参数,签名 payload 如下所示:
symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2×tamp=1668481559918&recvWindow=5000