# Basic Information
# Common Error Codes
Common HTTP Error Codes
- 4XX error codes are used to indicate wrong request content, behavior, format.
- 5XX error codes are used to indicate problems with the Bingx service.
# Error Codes
- 400 Bad Request – Invalid request format
- 401 Unauthorized – Invalid API Key
- 403 Forbidden – You do not have access to the requested resource
- 404 Not Found
- 429 Too Many Requests - Return code is used when breaking a request rate limit.
- 418 return code is used when an IP has been auto-banned for continuing to send requests after receiving 429 codes.
- 500 Internal Server Error – We had a problem with our server
- 504 return code means that the API server has submitted a request to the service center but failed to get a response. It should be noted that the 504 return code does not mean that the request failed. It refers to an unknown status. The request may have been executed, or it may have failed. Further confirmation is required.
- If it fails, there will be an error description included in the response body.
- Errors may be thrown from every interface.
Unless otherwise specified, all timestamps from the API are returned with millisseconds resolution.
Requests that have a 30+ second difference between the timestamp and the API service time will be considered expired or rejected. We recommend using the time endpoint to query for the API server time if you believe there may be time skew between your server and the API servers.
Decimal numbers are returned as "Strings" in order to preserve full precision. It is recommended that the numbers are converted to "Strings" to avoid truncation and precision loss.
Integer numbers (such as trade ID and sequences) are unquoted.
# Rate Limits
To prevent abuse, Bingx imposes rate limits on incoming requests. When a rate limit is exceeded, the system will automatically limit the requests.
# REST API
- Market Interface is the public interface. The rate limit of public interfaces is 20 requests every 1 second at most for each IP.
All requests are HTTPS-based. The Content-Type in the request header should be set as “application/json”.
1、Request Parameters: Encapsulate the request parameters according to the parameter requirements of the specific endpoint request.
2、Submit Request Parameters: Submit the encapsulated request parameters to the server via POST/GET/DELETE, etc.
3、Server Response: The server first performs parameter security verification on the user request data. When the verification is completed, the response data will be returned to the user in JSON format according to the service logic.
4、Data Processing: Process the response data from the server.
A successful response is indicated by HTTP status code 200 and may optionally contain a body. If the response has a body, it will be included under each resource below.