Introduction

Overview

MEXC Spot API provides developers with REST API and WebSocket streaming services for spot trading, supporting market data queries, account asset queries, order placement and cancellation, order queries, trade history queries, and real-time market subscriptions.

Developers can use the Spot API to build trading tools, market data systems, asset management systems, and automated trading applications. When calling private endpoints such as account and trade APIs, API Key authentication is required, and requests must be signed according to the Spot API signing rules.

API Key Setup

Many endpoints require an API Key. Please refer to this page to set up your API Key.
When setting up your API Key, for security we recommend configuring an IP access whitelist (if no whitelist is added, the key is valid for 90 days).
Trading pair settings: On the API management page, go to My API Key — Trading Pairs — Set to configure which trading pairs this API Key may trade.
Renewal: Starting 5 days before your API Key expires, go to My API Key — Action — Renew on the API management page to extend validity by 90 days.
Never share your API key or secret with anyone.

API Key Restrictions

Check the required permissions when creating an API Key.

API Library

We provide SDKs in five languages—Python, .NET, Java, JavaScript, and Go—so you can call APIs directly through the SDK.

https://github.com/mexcdevelop/mexc-api-demo

If you run into issues while using the SDK, please submit an issue for feedback.

Postman Collections

You can quickly try and use API endpoints via Postman collection. To learn more about using Postman, visit: MEXC API Postman

Access URL

Use the following base URL for API requests:

https://api.mexc.com

HTTP Return Codes

HTTP 4XX codes indicate an invalid request content, behavior, or format. The issue is on the requester's side.
HTTP 401 indicates authentication or permission errors.
HTTP 403 indicates a WAF (Web Application Firewall) limit violation.
HTTP 429 indicates the request rate limit is being exceeded; the IP may be banned soon.
HTTP 5XX codes indicate an issue on the MEXC server side.

Request Format

The API accepts GET, POST, PUT, or DELETE requests.

For GET endpoints, parameters must be sent in the URL Query String.
For POST, PUT, and DELETE endpoints, parameters may be sent entirely in the Query String, entirely in the Request Body, or using both the Query String and the Request Body.
When parameters are sent in the Request Body, the body must use the raw parameter string format key=value&key=value&..., not a JSON Object.
The Request Body may omit Content-Type; Content-Type: application/json is also supported. Even when application/json is used, the body content must still be the raw parameter string above, not a JSON Object.
Do not use Content-Type: application/x-www-form-urlencoded, or the request may return 700013 Invalid content Type.
The API itself does not require a fixed parameter order, but the parameter sequence used when generating the signature must match the sequence actually sent in the Query String / Request Body. Do not reorder parameters after generating the signature.
If the same parameter name appears in both the Query String and the Request Body, the Query String value takes precedence.

Response Format

All endpoints return data in JSON format.

Header Components

Request header parameters related to authentication and the request body:

Component	Description
`X-MEXC-APIKEY`	Access Key from the API Key
`Content-Type`	Optional. For Request Body scenarios, `application/json` is supported; do not use `application/x-www-form-urlencoded`

Content-Type: application/json only means this header is accepted by the API. It does not mean the Request Body should be a JSON Object. Spot V3 body parameters must use the raw parameter string format key=value&....

Signature

When calling SIGNED endpoints, in addition to the parameters required by the endpoint itself, you must also pass signature.
Request parameters other than signature may be sent in the Query String, the Request Body, or both; signature may be sent in the Query String or the Request Body, and signature itself is not included in the HMAC calculation.
Parameters in the Request Body use the raw key=value&... format.
Signatures use the HMAC SHA256 algorithm. The API Secret corresponding to your API Key is the HMAC SHA256 key.
totalParams = queryString + requestBody. Here, queryString and requestBody both refer to the actual parameter strings before signature is generated, excluding the signature parameter itself. Concatenate them directly with no extra & in between. After generating the signature, append signature to the Query String or the Request Body.
The signature output currently supports lowercase hexadecimal only.
For batch APIs, if parameter values contain special characters such as commas, URL-encode them when signing; encoding must use uppercase only.

Time Security

Pseudocode example

 if (timestamp < (serverTime + 1000) && (serverTime - timestamp) <= recvWindow)
  {
    // process request
  } 
  else 
  {
    // reject request
  }

All signed endpoints require a timestamp parameter—the Unix timestamp in milliseconds when the request was sent.
The server checks the timestamp in each request. If the request was sent more than 5000 milliseconds ago, it is considered invalid. This window can be customized with the optional recvWindow parameter.

Internet connectivity is not perfectly stable; latency between your client and the MEXC server may vary. That is why recvWindow exists. For high-frequency trading with strict timing requirements, adjust recvWindow as needed.

POST /api/v3/order Example

The following example places an order via the API on Linux bash using echo, openssl, and curl. The apiKey and secretKey are for demonstration only.

Key	Value
apiKey	mx0aBYs33eIilxBWC5
secretKey	45d0b3c26f2644f19bfb98b07741b2f5

Parameter	Value
symbol	BTCUSDT
side	BUY
type	LIMIT
quantity	1
price	11
recvWindow	5000
timestamp	1644489390087

Example 1: All parameters sent in the Request Body

HMAC SHA256 signature:

    $ echo -n "symbol=BTCUSDT&side=BUY&type=LIMIT&quantity=1&price=11&recvWindow=5000&timestamp=1644489390087" | openssl dgst -sha256 -hmac "45d0b3c26f2644f19bfb98b07741b2f5"
    (stdin)= fd3e4e8543c5188531eb7279d68ae7d26a573d0fc5ab0d18eb692451654d837a

curl command:

    (HMAC SHA256)
    $ curl -H "X-MEXC-APIKEY: mx0aBYs33eIilxBWC5" \
           -H "Content-Type: application/json" \
           -X POST \
           'https://api.mexc.com/api/v3/order' \
           --data-raw 'symbol=BTCUSDT&side=BUY&type=LIMIT&quantity=1&price=11&recvWindow=5000&timestamp=1644489390087&signature=fd3e4e8543c5188531eb7279d68ae7d26a573d0fc5ab0d18eb692451654d837a'

Example 2: All parameters sent in the Query String

HMAC SHA256 signature:

    $ echo -n "symbol=BTCUSDT&side=BUY&type=LIMIT&quantity=1&price=11&recvWindow=5000&timestamp=1644489390087" | openssl dgst -sha256 -hmac "45d0b3c26f2644f19bfb98b07741b2f5"
    (stdin)= fd3e4e8543c5188531eb7279d68ae7d26a573d0fc5ab0d18eb692451654d837a

curl command:

    (HMAC SHA256)
    $ curl -H "X-MEXC-APIKEY: mx0aBYs33eIilxBWC5" \
           -X POST \
           'https://api.mexc.com/api/v3/order?symbol=BTCUSDT&side=BUY&type=LIMIT&quantity=1&price=11&recvWindow=5000&timestamp=1644489390087&signature=fd3e4e8543c5188531eb7279d68ae7d26a573d0fc5ab0d18eb692451654d837a'

Example 3: Mixed Query String and Request Body

HMAC SHA256 signature:

    $ echo -n "symbol=BTCUSDT&side=BUY&type=LIMITquantity=1&price=11&recvWindow=5000&timestamp=1644489390087" | openssl dgst -sha256 -hmac "45d0b3c26f2644f19bfb98b07741b2f5"
    (stdin)= d1a676610ceb39174c8039b3f548357994b2a34139a8addd33baadba65684592

curl command:

    (HMAC SHA256)
    $ curl -H "X-MEXC-APIKEY: mx0aBYs33eIilxBWC5" \
           -H "Content-Type: application/json" \
           -X POST \
           'https://api.mexc.com/api/v3/order?symbol=BTCUSDT&side=BUY&type=LIMIT' \
           --data-raw 'quantity=1&price=11&recvWindow=5000&timestamp=1644489390087&signature=d1a676610ceb39174c8039b3f548357994b2a34139a8addd33baadba65684592'

Example 1: All parameters sent in the Request Body

queryString:

(empty)

requestBody:

symbol=BTCUSDT&side=BUY&type=LIMIT&quantity=1&price=11&recvWindow=5000&timestamp=1644489390087

totalParams:

equal to requestBody

Example 2: All parameters sent in the Query String

queryString:

symbol=BTCUSDT&side=BUY&type=LIMIT&quantity=1&price=11&recvWindow=5000&timestamp=1644489390087

requestBody:

(empty)

totalParams:

equal to queryString

Example 3: Mixed Query String and Request Body

queryString:

symbol=BTCUSDT&side=BUY&type=LIMIT

requestBody:

quantity=1&price=11&recvWindow=5000&timestamp=1644489390087

totalParams:

symbol=BTCUSDT&side=BUY&type=LIMITquantity=1&price=11&recvWindow=5000&timestamp=1644489390087

When building totalParams, the Query String and Request Body are concatenated directly; an & is not inserted between them. Therefore, in this example there is no & between LIMIT and quantity=1.

Rate Limits

REST API access is rate-limited. When the limit is exceeded, status 429 is returned: too many requests.

Endpoints that require an access key are rate-limited per account. Endpoints that do not require an access key are rate-limited per IP.

Rate Limit Description

Each endpoint indicates whether limits are counted by IP or UID (account), and the weight consumed per request. Different endpoints have different weights; more resource-intensive endpoints generally have higher weights.
IP-based and UID (account)-based limits are calculated independently. IP-weighted endpoints share 300 weight per 10 seconds; UID-weighted endpoints share 500 weight per 10 seconds.

Rate Limit Errors

When you receive 429, you must stop sending requests and must not abuse the API.
Continuing to exceed limits after receiving 429 will result in an IP ban.
Repeated violations extend the ban duration, from a minimum of 2 minutes to a maximum of 3 days.
Responses with 418 or 429 include a Retry-After header indicating the wait time in seconds—for 429, to avoid a ban; for 418, until the ban ends.

WebSocket Connection Limits

WebSocket server access is limited to 100 requests/s.
Connections that exceed the limit will be disconnected; IPs that are repeatedly disconnected may be blocked.
A single connection can subscribe to at most 30 streams.

FAQ

Q1: How many API Keys can a user apply?

Each account can create up to 30 API Keys. The validity of an API Key without a linked IP address is 90 days, and the API Key will expire automatically. Each API Key can be linked to a maximum of 10 IP addresses.

Q2: How many sub-accounts can a main account apply?

Each main account can create up to 30 sub-accounts. The sub-accounts will automatically inherit the main account rates. However, sub-accounts created via API cannot be logged in on Web.

Q3: Why are there often issues of disconnections and expired sessions?

If stable access is not possible, it is recommended to use Japan or Singapore AWS cloud servers for access.

Q4: What should I do after an error is reported for exceeding the limit frequency?

After exceeding the interface access frequency limit, you will not be able to continue accessing the interface. It will resume to normal after 10 minutes to keep the interface access frequency below the limit.

Q5: How many orders can an account place?

Each account can hold up to 500 valid orders that are not completely filled.

Q6: Why does WebSocket always disconnect?

If there is no valid subscription, it will disconnect in 30 seconds.
If the subscription is successful, and there is no traffic in 60 seconds, it will automatically disconnect.
To ensure a stable connection, a Pong reply is required upon receiving the Ping message sent from the server.

WebSocket currently allows subscription to up to 30 channels via a single link. Any subscription will be invalid after the limit is exceeded. To subscribe to more channels, it is recommended to create multiple links.

Contact us

MEXC API Telegram Group MEXC API Support Group
- For general API questions not covered in the documentation
- For API or WebSocket performance questions
- For market-making related questions
MEXC Customer Support website and in-app online customer service
- For wallet, SMS, 2FA, and related issues

Overview​

API Key Setup​

API Key Restrictions​

API Library​

Postman Collections​

Access URL​

HTTP Return Codes​

Request Format​

Response Format​

Header Components​

Signature​

Time Security​

POST /api/v3/order Example​

Rate Limits​

Rate Limit Description​

Rate Limit Errors​

WebSocket Connection Limits​

FAQ​

Q1: How many API Keys can a user apply?​

Q2: How many sub-accounts can a main account apply?​

Q3: Why are there often issues of disconnections and expired sessions?​

Q4: What should I do after an error is reported for exceeding the limit frequency?​

Q5: How many orders can an account place?​

Q6: Why does WebSocket always disconnect?​

Q7: Why am I unable to subscribe to multiple channels on WebSocket?​

Contact us​