Skip to main content

Integration Guide

Common Response Structure​

Response Example

{
  "success": true,
  "code": 0,
  "data": {
    "symbol": "BTC_USD",
    "fairPrice": 8000,
    "timestamp": 1587442022003
  }
}

Or

{
  "success": false,
  "code":500,
  "message": "系统内部错误!"
}

Request Format​

The current Open-API directly supports three request sources: APP, WEB, and OPEN-API. The corresponding APIs accept GET, POST, or DELETE requests. For POST requests, the Content-Type is application/json, and parameters are sent in JSON format (parameter names use camelCase). For GET requests, parameters are sent as request parameters (parameter naming rules are '_' delimited). Each request source uses a different authentication method:

  1. If the request source is OPEN-API, you must add the ApiKey parameter in the request header. If the request source is APP, you must add App-version in the header.

  2. Public endpoints do not require authorization or signatures.

  3. For private endpoints:

    • If the request source is WEB or APP, include the Authorization parameter in the header with the corresponding token value.

    • If the request source is OPEN-API, include the ApiKey, Request-Time, Signature, and Revc-Window (optional) parameters in the header. Signature is the signature string, with rules as follows:

      1. Obtain the request parameter string first; if there are no parameters, use an empty string "".

      For GET/DELETE requests, sort business parameters in dictionary order, concatenate them with &, and produce the final string to sign (for batch APIs, if parameter values contain commas or other special characters, these must be URL-encoded during signing).

      For POST requests, the parameters to sign are the JSON string (no dictionary sorting required).

      1. After obtaining the parameter string, build the target string for signing as: accessKey + timestamp + parameterString.

      2. Use the HMAC-SHA256 algorithm to sign the target string, and include the resulting signature in the request header.

      3. Business parameters that are null are not included in the signature. Path parameters are also excluded from the signature. Note: For GET requests, when appending parameters to the URL, if a parameter is null, the backend may parse it as "". Therefore, for GET requests, if a parameter is null, do not pass that parameter, or set its value to "" when signing; otherwise, signature verification may fail!

      4. When sending the request, place the value used for req_time during signing into the Request-Time header, the generated signature string into the Signature header, and your API key’s Access Key into the ApiKey header. Other business parameters should be sent as usual.

  4. For APP and WEB, POST requests must be signed. The signing rule is:

    md5(time + body + md5(token + time).substring(7))

    where time is the current timestamp and body is json parameter. The time difference with the server must be within 2 minutes. You can get the server time via the api/v1/contract/ping endpoint. After computing the signature, put the signature string in the header with key x-mxc-sign, and put time in the header with key x-mxc-nonce.

Time Security​

All signed endpoints require the Request-Time header parameter, which is the timestamp in milliseconds as a string. The server validates the request’s time window. If, upon receiving the request, the req_time is more than 10 seconds (default) behind or ahead of the server time (this window can be customized by sending the optional Recv-Window header parameter; its maximum value is 60, and using a value above 30 seconds is not recommended), the request is considered invalid.

Create API Key​

Users can create an API key in the MEXC user center. It consists of two parts: the Access key (API access key) and the Secret key (used for signature calculation and verification).

You can click here to create an API Key.

When creating an API Key, you can choose to bind IP addresses. API Keys that are not bound to IP addresses are valid for 90 days. (Binding IP addresses is strongly recommended.)

These two keys are closely related to your account security. Never disclose them to others under any circumstances.