*Blog post updated on 11 December at 02:00 UTC to reflect additional routes subject to second layer rate limits: POST /api/v1/order/bulk and PUT /api/v1/order/bulk.
As part of our commitment to operate a fair and efficient marketplace, we are introducing a more granular layer of rate limiting to order management routes on 15 December 2020 from 23:00 UTC. This is designed to further optimise the overall trading experience for BitMEX users.
The current rate limiting system places a cap on the number of requests a user can send to the platform in a 60 second period, and allows users to send their full remaining quota of requests in a single instant.
We are introducing an additional layer of rate limiting that will limit the number of order management requests that can be sent per second. This will help more evenly distribute request bursts from individual users, resulting in fairer treatment of client order flow through the platform. This additional rate limit is expected to impact less than 1.5 percent of users based on analysis of platform activity over the last 60 days.
The new second layer rate limit on the number of requests that can be sent in a single second will be introduced to the following routes:
- POST /api/v1/order
- POST /api/v1/order/bulk
- PUT /api/v1/order
- PUT /api/v1/order/bulk
- DELETE /api/v1/order
- DELETE /api/v1/order/all
- POST /api/v1/position/isolate
- POST /api/v1/position/leverage
- POST /api/v1/position/transferMargin
By default, all accounts start with the same rate limits:
- 60 requests per minute
- 10 requests per second
Full details of all our rate limits can be found on our REST API documentation along with details on how to request an increase to those limits.
There will be a soft release of the new limiter on 10 December 2020 from 23:00 UTC. From this time, responses for the affected routes will include the
x-ratelimit-remaining-1s header. Requests that exceed the limit will still be successful, but the value of the
x-ratelimit-remaining-1s header will be 0. This means that orders will still go through and the status code for valid requests will be a 200, not a 429.
On 15 December 2020 from 23:00 UTC, requests that breach the limit will be rejected with a 429 status code and a one hour ban will be levied if a large number of requests are rejected in a short period of time.
If you would like to test the new rate limiter you can do so in our Testnet environment where it has already been fully released.