Update to bulk order request functionality

Beginning on 20 February at 04:00 UTC, market orders will no longer be permitted in bulk order requests submitted through the API. This includes both orders submitted with ordType=Market and implicit market orders (orders submitted with a side but without a price). After this time, including a market order in your bulk order request will result in the entire request being rejected. This functionality update is part of the ongoing simplification of our API and trading system architecture.

Deprecation of MarketWithLeftoverAsLimit order type

As part of the ongoing simplification of our API and trading system architecture, the below order type will no longer be supported after 04:00 UTC on Friday 8th February 2019:

  • MarketWithLeftoverAsLimit

Orders submitted with an order type value of MarketWithLeftoverAsLimit after this time will be rejected. Furthermore, any open order of this type 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.

Notice of Websocket API internal upgrade

As part of the ongoing capacity improvements to the platform, there will be a scheduled update to the Websocket API infrastructure at 16:00 UTC on 16th January.

There is no planned downtime to the trading engine for this change however please note that a momentary interruption in the deltas published on the websocket feed is expected at 16:00 UTC. Shortly after this all websocket connections will be forcibly disconnected to ensure no websocket client is left with an inconsistent view of their own orders, positions or the public order book upon reconnection. This change should otherwise be transparent to users.

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

Traders,

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: https://blog.bitmex.com/api_announcement/addition-of-position-endpoints-to-load-shedding/
  • 3 Dec 2017: https://blog.bitmex.com/site_announcement/update-to-system-overload-policy/
  • 9 Nov 2017: https://blog.bitmex.com/api_announcement/scheduled-maintenance-november-9-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: https://blog.bitmex.com/site_announcement/update-to-system-overload-policy/
  • 9 Nov 2017: https://blog.bitmex.com/api_announcement/scheduled-maintenance-november-9-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 52.214.218.140 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.