Skip to main content

Precautions

Enabling Accounts​

Spot Trading​

Spot trading is automatically enabled upon account registration. Users can activate API access for spot trading during the API creation process.

Futures Trading​

To enable Futures trading, users must first activate their Futures account. When setting restrictions for "Futures" for the first time while creating an API, a pop-up window will appear prompting users to agree to the terms and conditions. Upon agreement, the Futures trading account will be activated.

Position Limit​

Futures Trading​

For details on futures position limits, please visit https://www.coinw.com/trading-rules

Frequency Limit​

1. Futures Trading Rate Limit:​

Futures Trading APIs are governed by two types of rate limits:

(a) Per-Interface Rate Limit​

For Futures Trading, each RESTful API endpoint is subject to a per-interface rate limit based on both IP and User ID. Per-interface rate limits are documented within each API interface, specifically under the "Frequency Limit" section.

If a user exceeds the per-interface rate limit, the following error will be returned:

{"code": 29001,"msg": "API access frequently"}

If the user is accessing only a single API endpoint and encounters the error above error, this indicates that the per-interface rate limit for that endpoint has been triggered. To maintain high availability and performance for all users, clients are encouraged to implement appropriate API monitoring.

(b) Global Rate Limit​

In addition to per-interface rate limit, there is a global rate limit applied across all Futures RESTful APIs endpoints.

A global rate limit is the maximum number of requests allowed across across all Futures RESTful APIs endpoints combined within a specific time period. It ensures total request volume stays within system-wide limits, regardless of which endpoints are called.

Group A: Market Data Endpoints​

The following market data endpoints are subject to global rate limiting based on IP address:

  • GET /v1/perpumPublic/klines
  • GET /v1/perpumPublic/tickers
  • GET /v1/perpumPublic/ticker
  • GET /v1/perpumPublic/trades
  • GET /v1/perpumPublic/depth

Rate Limit: Requests to group A endpoints are aggregated by IP address. Each IP is limited to 30 requests per second.

Group B: Remaining Futures Endpoints​

All remaining Futures RESTful API endpoints not included in Group A are classified as Group B and are subject to global rate limiting based on User ID.

Rate Limit: Requests to group B endpoints are aggregated by User ID (UID). Each UID is limited to 100 requests per second.

If thresholds of either Group A or Group B are exceeded, the system will respond with:

{"code": 29001,"msg": "API access frequently"}

If the user is accessing multiple API endpoints and encounters the above error, this indicates that the Global rate limit has been triggered. To maintain high availability and performance for all users, clients are encouraged to implement appropriate API monitoring.

Note: In addition to Per-Interface and Global Rate Limits, rate limiting may also occur due to overall network congestion. This is not caused by individual user activity but by high system-wide API demand.

2. Spot Trading Rate Limit​

Spot Trading APIs are governed by two types of rate limits:

(a) Per-Interface Rate Limit​

For Spot Trading, each RESTful API endpoint is subject to a per-interface rate limit based on both IP and User ID. Per-interface rate limits are documented within each API interface, specifically under the "Frequency Limit" section.

If a user exceeds the per-interface rate limit, the following error will be returned:

{"code": 29001,"msg": "API access frequently"}

If the user is accessing only a single API endpoint and encounters the above error, this indicates that the per-interface rate limit for that endpoint has been triggered. To maintain high availability and performance for all users, clients are encouraged to implement appropriate API monitoring.

(b) Global Rate Limit​

In addition to per-interface rate limit, there is a global rate limit applied across all Spot RESTful APIs endpoints.

A global rate limit is the maximum number of requests allowed across across all Spot RESTful APIs endpoints combined within a specific time period. It ensures total request volume stays within system-wide limits, regardless of which endpoints are called.

  1. Each IP address is allowed up to 100 requests per second.
  2. Each User ID is allowed up to 300 requests per second.

If either of above threshold are are exceeded, the platform will respond with following error:

{"code": 29001,"msg": "API access frequently"}

If the user is accessing multiple API endpoints and encounters the above error, this indicates that the Global rate limit has been triggered. To maintain high availability and performance for all users, clients are encouraged to implement appropriate API monitoring.

Note: In addition to Per-Interface and Global Rate Limits, rate limiting may also occur due to overall network congestion. This is not caused by individual user activity but by high system-wide API demand.

3. API Rate Limiting Policy – Client Guide​

This guide outlines how to use the API responsibly and what happens if your normal usage count (i.e., the combined number of per-interface rate limit error and global rate limit error) is exceeded.

(a) Normal Usage Count​

As long as the interface rate limits and global rate limits are not triggered, and the number of API requests remains within the specified thresholds within any 10-second time window, your access will remain unimpeded and no error messages will be returned.

CategoryError count (per 10 seconds)
User Account (UID)60
IP Address80
Device + IP60

Note: The above limits are automatically reset every 10 seconds. As long as the frequency limit is followed within each time interval, API usage will not be interrupted; If the normal usage times are exceeded, the system will enable stricter frequency limit control measures. To avoid triggering stricter frequency limit measures, it is recommended that you strictly follow the above frequency requirements.

(b) What Happens If a User Exceeds the Normal Usage Count?​

1. Warning Phase (5 Minutes)​

If you exceed the normal usage count, your API access enters a temporary warning phase lasting 5 minutes. During this phase:

  1. The per-interface rate limit for all API endpoints is reduced by 50%. Example: If an endpoint originally allowed 10 requests per 2 seconds, it will now allow only 5.*
  2. You may experience more frequent "rate limit exceeded" errors.

If your error count remains within the thresholds listed below during the 5-minute window, your API access will automatically return to normal.

CategoryError count (per 10 seconds)
User Account (UID)60
IP Address80
Device + IP60

If the error count exceeds these thresholds during the warning phase, your API access will be temporarily banned.

2. Temporary Ban (30 seconds)​

During temporary ban phase:

  1. All API access will be blocked for 30 seconds.
  2. After 30 seconds, your access will automatically return to normal usage count.

However, frequent bans within an 8-hour window can lead to blacklisting.

3. Blacklist​

If a user exceeds the ban threshold within an 8-hour window, they will be blacklisted.

CategoryMaximum Bans in 8 Hours
User Account10
IP Address10
Device + IP5

During the blacklist phase:

  • All API access is disabled for 8 hours.
  • Users must contact customer support for assistance.

If the threshold is not breached within 8 hours, your API access will revert to normal usage count.

Mega Coupon​

CoinW Futures offers Mega Coupons, which can be used as initial margin or to offset trading fees, losses, and funding payments in futures trading. For more details, visit at https://coinw.zendesk.com/hc/en-us/articles/23111150445977-Introduction-to-Futures-Mega-Coupon

Precautions​

Futures Trading​

  1. It is strongly recommended to review the "Precautions" section in each interface to avoid any misunderstandings or inconveniences.

  2. CoinW allows traders to open both long and short positions on the same asset simultaneously, enabling hedging functionality and supporting the development of more flexible and sophisticated trading strategies.

  3. Typically, a position is closed by placing an identical order in the opposite direction. However, this approach does not apply on CoinW. Placing an order in the opposite direction will open a new position instead of closing the original one, resulting in two active positions. To properly close a position, refer to Futures > Place Orders > Close a Position. For batch closing of positions, refer to Futures > Place Orders > Close Batch Positions. Note: While the platform displays positions from user's own orders, copy trading, and strategy square uniformly, the OpenAPI only supports operations (such as closing positions or canceling orders) for user's own orders. For positions generated by copy trading and strategy square, API operations are not permitted, and users should use the platform's corresponding functions.

  4. To set trailing stop loss, take profit, and stop loss, refer to Futures > Place Orders.

  5. CoinW provides an interface to adjust position layout. For more details, please refer to Futures > Account & Assets > Set Margin Mode. By selecting "Merge", all positions of the same instrument and direction are merged. By selecting "Split", new positions will be kept separate with a unique position ID.

  6. Some interfaces return the following response. "code:0" indicates a successful operation.

    {'code': 0, 'msg': ''}

  7. Funding Time Restrictions: During the funding period, operations related to transaction such as placing orders or closing positions are not permitted. Attempting these actions will result in an error response. The funding process typically takes 30 to 40 seconds. It is recommended to wait at least 1 minute before retrying transaction related operations. For the exact funding fee schedule, please refer to the official webpage.

  8. WebSocket subscription data does not guarantee the order of timestamps. Therefore, it is recommended that users perform their own checks and data cleaning after receiving the data.

  9. Returning an order ID does not mean the order has been filled. Returning an orderId only means that the system has accepted your order request, but the order may be canceled during matching — it does not guarantee execution. To confirm whether the order has been filled, please call the Check Orders APIs or Positions Information API's.

Spot Trading​

  1. WebSocket subscription data does not guarantee the order of timestamps. Therefore, it is recommended that users perform their own checks and data cleaning after receiving the data.