Rate Limit Rule (Classic)

RESTful Rate Limit

1. Introduction of Rate Limit Pool

The platform uses multiple Rate Limit Pools to manage API request rates across different business scenarios.

Each API endpoint is assigned to a specific Rate Limit Pool. The corresponding Rate Limit Pool is indicated in the API documentation for each endpoint.

When a user makes an API request, the system controls the request rate based on the Rate Limit Pool assigned to the endpoint and the user's corresponding rate limit quota.

API Rate Limit Pools are currently divided into the following two categories:

1.1 Private Rate Limit Pool

The Private Rate Limit Pool applies to API endpoints that require authentication. Rate limits for these endpoints are managed based on the UID.

1.2 Public Rate Limit Pool

The Public Rate Limit Pool applies to API endpoints that can be accessed without authentication. Rate limits for these endpoints are managed based on the IP address.
If you need to make a large number of requests to public endpoints, we recommend using the WebSocket API instead of the REST API whenever the corresponding WebSocket endpoint is available.
To avoid IP-based rate limits, you can use the following approaches:

Bind multiple IP addresses (IPv4 or IPv6) to a single server.

Send requests from different IP addresses.

2. Weight

2.1 Weight Rules

When a user makes an API request, the endpoint's Rate Limit Weight is counted against the user's rate limit quota and updated every 1 second, starting from the time the user's first request arrives.

For the specific Rate Limit Weight of each endpoint, please refer to the rate limit rules specified in the corresponding API documentation.

If the quota of any Rate Limit Pool is exhausted within a 1-second window (meaning the rate limit is exceeded), the API will return HTTP code 429 with error code 429000. The response header will also indicate when the user can send requests again.
During this period, the user must stop sending requests and wait until the Rate Limit Pool quota is reset before continuing.

For example:
When user 00123 has VIP Level 5, the user's total Rate Limit quota is 700 requests/second.
If each Batch Cancel Orders By ID request consumes a weight of 4, the user's remaining quota will be:

After the first batch cancellation request: 696

After the second batch cancellation request: 692

And so on.
If the quota is not fully consumed within the 1-second window, the Rate Limit Pool quota will be reset at the beginning of the next window, and the available quota will return to 700.

2.2 HTTP Header

Each API response includes the following HTTP headers, which provide information about the total Rate Limit Pool quota, remaining Rate Limit Pool quota, and countdown to the next quota reset in milliseconds.

Using the example above, after user 00123 sends the first batch cancellation request, the response headers will be:

gw-ratelimit-limit: 700
gw-ratelimit-remaining: 696
gw-ratelimit-reset: 489 (ms)

3. Rate Limit Quota by VIP Level

Users at different VIP levels are assigned corresponding rate limit quotas in each Rate Limit Pool.

VIP Level/Rate Limit Pool	Spot (include Margin)	Futures	Management	Earn	Copying Trading	Broker	Public
VIP0	4000/30s	2000/30s	2000/30s	2000/30s	2000/30s	2000/30s	2000/30s
VIP1	6000/30s	2000/30s	2000/30s	2000/30s	2000/30s	2000/30s	2000/30s
VIP2	8000/30s	4000/30s	4000/30s	2000/30s	2000/30s	2000/30s	2000/30s
VIP3	10000/30s	5000/30s	5000/30s	2000/30s	2000/30s	2000/30s	2000/30s
VIP4	13000/30s	6000/30s	6000/30s	2000/30s	2000/30s	2000/30s	2000/30s
VIP5	16000/30s	7000/30s	7000/30s	2000/30s	2000/30s	2000/30s	2000/30s
VIP6	20000/30s	8000/30s	8000/30s	2000/30s	2000/30s	2000/30s	2000/30s
VIP7	23000/30s	10000/30s	10000/30s	2000/30s	2000/30s	2000/30s	2000/30s
VIP8	26000/30s	12000/30s	12000/30s	2000/30s	2000/30s	2000/30s	2000/30s
VIP9	30000/30s	14000/30s	14000/30s	2000/30s	2000/30s	2000/30s	2000/30s
VIP10	33000/30s	16000/30s	16000/30s	2000/30s	2000/30s	2000/30s	2000/30s
VIP11	36000/30s	18000/30s	18000/30s	2000/30s	2000/30s	2000/30s	2000/30s
VIP12	40000/30s	20000/30s	20000/30s	2000/30s	2000/30s	2000/30s	2000/30s

4. Master-Sub Account Rate Limit Rules

The rate limits for the master account and sub-accounts are independent of each other.
Therefore, if a particular endpoint has higher access requirements, requests can be distributed across sub-accounts to increase the available rate limit quota.

5. Additional Limits & Requesting Higher Limits

5.1 Server Overload Limits

In addition to the standard rate limits, temporary rate limits may be triggered when the server is overloaded.
In this case, the system will return error code 429000, but the response header will not contain individual rate limit information. These limits do not count toward the standard rate limit quota. We recommend trying again later.

5.2 Requesting Higher Limits

If you are a professional trader or market maker and require a higher rate limit quota, please send the following information to api@kucoin.com:

KuCoin account information

Reason for the request

Estimated trading volume

WebSocket Rate Limit

1. Maximum Concurrent Connections

Limit: ≤ 800 concurrent connections
Scope: Private (authentication required) endpoints are counted by UID; public (authentication not required) endpoints are counted by IP address.
The master account and sub-accounts are completely independent (different UIDs).

2. Client-to-Server Messages

Limit: 100 messages per 10 seconds
Scope: Calculated per connection.

Maximum Topics per Request: 100
Scope: Calculated per connection.

4. Maximum Number of Topics per Connection

Spot / Margin: ≤ 400 topics
Futures: Unlimited

5. Automatic Load Balancing

The Automatic Load Balancing has been launched to further improve API service stability and latency performance.
The system will dynamically balance traffic and allocate resources based on the real-time load conditions of each shard, helping users achieve more stable connections and improved latency performance.
During future load balancing switches, some WebSocket connections may be temporarily disconnected by the server. These switches are expected to occur at most once or twice per week. Users may reconnect to restore normal connectivity.

Rate Limit Rule (Classic)

RESTful Rate Limit#

1. Introduction of Rate Limit Pool#

1.1 Private Rate Limit Pool#

1.2 Public Rate Limit Pool#

2. Weight#

2.1 Weight Rules#

2.2 HTTP Header#

3. Rate Limit Quota by VIP Level#

4. Master-Sub Account Rate Limit Rules#

5. Additional Limits & Requesting Higher Limits#

5.1 Server Overload Limits#

5.2 Requesting Higher Limits#

WebSocket Rate Limit#

1. Maximum Concurrent Connections#

2. Client-to-Server Messages#

3. Subscribe / Unsubscribe Requests#

4. Maximum Number of Topics per Connection#

5. Automatic Load Balancing#