Basic Info

Request Rate Limit


Rate limit 1.0:

The limit strategy of private endpoints will restrict account by userid. The limit strategy of public endpoints will restrict IP. Currently Kucoin has three rate limits, which are as follows:

1、 error code: 1015, according to the IP rate limit, Cloudflare is based on the IP limit, all endpoint share the rate limit, currently 500/10s, the background may be fine-tuned, block 30s. Cloudflare does not have the configuration of the ip whitelist, so it cannot be specially adjusted, but this problem can be avoided, such as using the Websocket instead of the Rest(if the interface supports it). You can also use one server to bind multiple ip addresses (ipv4 or ipv6), and then use different ip for different sub-accounts.

2、 error code: 200002, rate limit of each private endpoint of kucoin, For the specific rate limit of each interface, please refer to the "Old Version API Documentation". based on user uid+endpoint mode limit, block10s. For example, if a certain endpoint is called too frequently, you may encounter this problem. It is recommended to reduce the rate of use of that interface.

3、 error code: 429000, kucoin stand-alone capacity limit. It can be understood that the server is overloaded. If it is in spot, it is recommended to use a high-frequency account, which can reduce 429000 errors and reduce delays. The following is a tutorial on the use of high-frequency accounts:

Rate limit 2.0 (Coming soon, expected in early October):

Compared with 1.0, users can more freely break through the rate limit of a single interface according to the strategy, and freely coordinate the use of interfaces, which makes the strategy that relies too much on certain interfaces run smoothly. For example, in the 1.0 rate limit, the order cancellation interface of high-frequency users is relatively restricted, but under the new logic, as long as other interfaces are not requested too much, the order cancellation can be 2-3 times that of the previous one, so it can be realized higher rate limit requirements That is to say, the new rate limit rules are equivalent to determining the resource supply and realizing the optimal configuration of the interface according to user needs.

The specific rules of REST rate limit 2.0 are as follows:

  • Resource pool: Each API resource pool has a certain quota, the specific amount depends on the VIP level: Public rate limit Spot rate limit (including margin) Futures rate limit Management rate limit
Level Spot Futures ManageMent Public
VIP1 3000/30s 2000/30s 2000/30s 1000/30s
VIP2 6000/30s 4000/30s 4000/30s 1000/30s
VIP3 10000/30s 5000/30s 5000/30s 1000/30s
VIP4 13000/30s 6000/30s 6000/30s 1000/30s
VIP5 16000/30s 7000/30s 7000/30s 1000/30s
VIP6 20000/30s 8000/30s 8000/30s 1000/30s
VIP7 23000/30s 10000/30s 10000/30s 1000/30s
VIP8 26000/30s 12000/30s 12000/30s 1000/30s
VIP9 30000/30s 14000/30s 14000/30s 1000/30s
VIP10 33000/30s 16000/30s 16000/30s 1000/30s
VIP11 36000/30s 18000/30s 18000/30s 1000/30s
VIP12 40000/30s 20000/30s 20000/30s 1000/30s
  • Weight: When a user requests any API, the weight of this interface will be deducted and updated every 30s (starting from the arrival time of the user's first request). For specific interfaces, please refer to the rate limit weight regulations under each interface. If the quota of any resource pool is used up within 30s, that is, after the rate limit is exceeded, an error message of http code:429, error code:429000 will be returned, and the request can be re-requested after how long the request header shows. At this time, user needs to stop accessing and wait until the resource quota is reset before continuing to access.

  • Request header: The returned information of each request will carry the following information: total resource pool quota, resource pool used quota (or remaining quota), resource pool quota reset timestamp (milliseconds). "gw-ratelimit-limit": 500 "gw-ratelimit-remaining": 300 "gw-ratelimit-reset": 1489791662

  • Public rate limit: It is based on IP rate limitation. If there is a large demand for the use of public interfaces, it is recommended to use the Websocket interface instead of the Rest interface (if the interface supports it). You can also use one server to bind multiple IP addresses (ipv4 or ipv6), or use different IPs for different sub-accounts to avoid IP rate limit issues.

  • Spot rate limit (including margin), futures rate limit, and management rate limit: all are based on uid, and the request header will carry the rate limit information of the resource pool, such as the remaining rate limit times, rate limit cycle time, etc. And the rate limit of the sub-account and the master account are independent of each other at the API request level, that is to say, if the demand for such interface access is relatively large, it can also be solved by using the sub-account

In addition to the regular rate limit, server overload may also cause the rate limit. After the rate limit, the error code is 429000, but the request header will not carry other personal rate limit information. This type of rate limit does not count as the number of rate limits. It is recommended to try again later.

In addition, during the transition period between 1.0 and 2.0, you may still encounter error code 1015. It is recommended to try again later. If it occurs frequently, please contact the official community to deal with it