Deprecation of contingent orders

As part of the ongoing simplification of our API and trading system architecture, the below order types will no longer be supported after 12:00 UTC on Saturday 10th November 2018:

  • OCOOne Cancels the Other
  • OTOOne Triggers the Other
  • OUOAOne Updates the Other Absolute
  • OUOPOne Updates the Other Proportional

Orders submitted with a contingencyType field after this time will be rejected. Furthermore, any open contingent orders will be automatically cancelled shortly after the above deadline. As such, please ensure any trading strategies using these order types are appropriately updated to reflect this change.

Deprecation of SimpleOrderQty functionality

Orders submitted using the simpleOrderQty field will no longer be supported from 12:00 UTC on Friday 26th October 2018. Any orders submitted using the simpleOrderQty field after this time will be rejected. Any existing open orders submitted using a simpleOrderQty will automatically be cancelled shortly after the above time.

Please further note that within the coming weeks updates via the Websocket API or GET requests to the REST API for the below fields will return a null value:

  • position: simpleQty, simpleCost, simpleValue, simplePnl, simplePnlPcnt
  • order: simpleOrderQty, simpleLeavesQty, simpleCumQty
  • execution: simpleOrderQty, simpleLeavesQty, simpleCumQty

These fields may also be removed entirely from these schemas at a future date. We will make another announcement before removing the fields entirely from the message schemas. We strongly recommend API users to update any clients that use these fields before the above deadline to avoid any disruption.

CloudFlare Edge Deployment and Latency


A previous version of this article detailed a rollout to CloudFlare at our edge. Due to latency and connection stability issues, CloudFlare has been removed. We are investigating long-term viability and will not re-initiate until we are sure we can satisfy our customers’ high expectations.

Removal of AllOrNone ExecInst

As part of BitMEX’s engine optimization process, breaking API changes are occasionally required. BitMEX strives to avoid imposing these whenever possible.

Please ensure you update your API clients appropriately to avoid any disruption to your trading strategies.

  • The order Execution Instruction (ExecInst) AllOrNone will be removed on 00:00 UTC Monday 14th May. Orders using AllOrNone will be rejected.

Load Shedding and “Close” execInst

It has come to our attention that some API consumers are using the Close execInst as an escape valve to continue quoting one side of the market during overload conditions. This was not the intention of the exclusion – the intent was to allow full position closure, primarily for frontend users.

Close orders are now subject to load shedding if they contain a quantity. If you do intend to close your full position, please omit the orderQty field in your order. The absence of this field, in combination with Close, is interpreted as your full position size.

See also previous announcements on Load Shedding:

  • 26 Feb 2018:
  • 3 Dec 2017:
  • 9 Nov 2017:

Addition of Position Endpoints to Load Shedding

Starting today, the following endpoints will be subject to load shedding:

  • POST /position/leverage
  • POST /position/isolate
  • POST /position/transfer
  • POST /position/riskLimit

Order Cancel and the Close execInst via the frontend remain exempt from shedding.

We have a number of performance improvements in the short-term pipeline for these functions but must temporarily restrict them to prevent resource starvation.

See also previous announcements on Load Shedding:

  • 3 Dec 2017:
  • 9 Nov 2017:

Notice of Primary IP Change

As BitMEX scales, it is now necessary for us to spread ingress endpoints.

We will be migrating the primary public ingress point from its current network-routed to a dynamic setup that will serve a larger number of ingress IPs based on load. This action is in response to recent DDoS activity and is part of a larger scaling effort. The new endpoints have begun serving a small percentage of traffic, which we will increase through the week.

This action should not affect the vast majority of API consumers. As with all web services, we strongly discourage hardcoding IP addresses. Please ensure your tools do not cache DNS records for an unreasonably long time.

Order Placement Limits

Starting December 11th, 2017 at 12:00 UTC, the following limits will be applied:

(1) Maximum 200 open orders per contract per account;
(2) Maximum 10 stop orders per contract per account;
(3) Maximum 10 contingent orders per contract per account.

When placing a new order that causes these caps to be exceeded, it will be rejected with the message “Too many [open|stop|contingent] orders”.

These caps are designed to improve the overall trading experience on BitMEX and will be reviewed and updated periodically.

Completed Maintenance: November 30, 3:30 UTC

Maintenance is complete.

We have successfully tested a new hardware configuration for our trading engine. We will be taking down the engine at 3:30 UTC (in 30 minutes from the time of this publication) for about 15 minutes to do the switchover. After completion, we will tweet and initiate a 3-minute cancel-only period.

Orders left open over maintenance will remain open, as will positions. If this concerns you, please cancel your orders and/or close your positions before the maintenance interval.

Any trigger orders (such as stops) will *not* activate during this period. Once trading restarts, if the price at that time would trigger your order, it will trigger then.

Limits to Bulk Order Endpoints

Starting November 12, 2017, at 12:00 UTC, the API will limit calls to bulk order endpoints to a maximum count of 100. Calls with a larger number of orders will be rejected with a status code of 400 and the message Too many orders provided. The maximum count allowed is 100.

Scheduled Maintenance: November 9, 2017

As part of scaling BitMEX, we will be taking the following actions:

The BitMEX platform will halt trading on November 9 at 18:00 UTC for a database upgrade. We expect this upgrade to take 10 minutes. Once the platform is back online, we will notify via Twitter, enter a cancel-only period for 5 minutes, and trading will resume. The following additional changes will be made:

  1. The tick size on XBT products will be increased from 0.1 to 0.5 USD, and on XBJ products from 1 to 100 JPY. If you are using automated tools, please ensure they are aware of the change and submitting/amending with the proper tick size. Orders with an incorrect tick size will be rejected. These changes are already on Testnet. If you have existing orders at the time of the change, they will be amended away from the mid to match the new tick size.
  2. To help improve responsiveness during high-load periods, the BitMEX trading engine will begin load-shedding when requests reach a critical queue depth. When this happens, you will quickly receive a 503 status code with the message “The system is currently overloaded. Please try again later.” The request will not have reached the engine, and you should retry after at least 500 milliseconds.
  3. We will be migrating the trading engine to a newer server with a more modern, higher-frequency processor. We expect this to give us a roughly 25% performance improvement.

All of these changes will improve quality of service dramatically during high load. Traders will receive immediate feedback about overload and can choose to resubmit or amend, rather than waiting many seconds for an order to execute or fail.

We are working daily to improve engine throughput during high-volatility periods and we appreciate your support and use of BitMEX. As always, if you have questions or comments about our API, please reply to this email.


Welcome to the BitMEX API RSS feed. Changes and updates to the BitMEX API will be announced here.

The feed can be imported from this link.