Binance USDⓈ-M Futures API: How to Make Open Orders Expire on Time

Binance

27 October 2026

To make unfilled orders on Binance USDⓈ-M Futures expire at a set time, API users should use timeInForce=GTD and pass the goodTillDate parameter at the same time. This is a built-in timed expiry feature of Binance USDⓈ-M Futures, so you don't need to write your own scheduled task to cancel orders. There are three key rules: goodTillDate must be greater than the current time plus 600 seconds, must be less than 253402300799000, and the timestamp you pass only keeps second-level precision — the millisecond part will be ignored. If you need an order that is "Maker only and expires at a set time", GTD and post-only cannot be used together. You must choose one or the other.

Binance Exchange
The world's largest cryptocurrency exchange by trading volume,leading in security and liquidity.
New user benefit: Enjoy 20% off trading fees upon registration!

First confirm your order type supports GTD

GTD is one of the values for timeInForce, and it applies to limit orders. In Binance USDⓈ-M Futures, the GTD time in force type means "valid until a specific time, then automatically canceled when expired". By comparison, GTC is also a resting order, but it stays valid for one year after placement, and is only automatically canceled after that year. For the goal of "making unfilled orders expire on time", GTD is the direct match. Using GTC and then polling to cancel orders yourself means maintaining extra logic outside the API, which is not necessary.

Note that IOC and FOK are not suitable for this scenario: IOC immediately cancels the unfilled portion, and FOK cancels the entire order if it cannot be fully filled immediately. They solve the question of "whether to wait", not "wait until a certain time and then expire".

What exactly to pass when placing an order

In the USDⓈ-M Futures order endpoint, set timeInForce to GTD, and fill in the goodTillDate field with the timestamp at which you want the order to be automatically canceled. The official documentation states: when timeInForce is GTD, goodTillDate is a required parameter; the timestamp must be greater than the current time plus 600 seconds, and less than 253402300799000; the timestamp you pass only keeps second-level precision, and the millisecond part will be automatically ignored.

For example: suppose you want a BTCUSDT limit order to expire at UTC time 12:00:00 on October 27, 2026. The corresponding timestamp needs to be the Unix millisecond value of that moment. If the timestamp your code generates has millisecond digits, such as ...448, Binance will ignore the 448, and the actual expiration time will fall on the whole second. In most cases this has no impact, but if you need sub-second precision for the expiration moment, you should know that this truncation is platform behavior, not a problem with your code.

The 600-second minimum lead time is an easy trap to fall into. If your strategy only calculates a "expire in one minute" timestamp when the market moves quickly, the API will reject it directly. A safer approach is to validate in your order placement logic whether goodTillDate meets the now + 600s lower limit. If it does not, either switch to GTC with your own cancellation logic, or set the expiration time further out.

Another limitation worth noting: GTD and post-only cannot be combined. If your strategy requires the order to be a maker order and also needs timed expiration, Binance's native GTD cannot satisfy both at the same time. In this case, your choices are: either give up post-only and use GTD for native expiration, or keep post-only and place a GTC order while maintaining your own cancellation scheduler. The former is simpler, while the latter gives you more control over execution quality for maker strategies. It depends on which side your strategy cares about more.

How to confirm the order will really expire after placing it

After submitting a GTD order, don't just look at the order ID returned by the order endpoint and assume the setting took effect. Query the order details through the order query endpoint, and check whether timeInForce in the response is GTD, and whether goodTillDate matches the value you passed. If timeInForce shows GTC, it means your parameters did not take effect — a common reason is that the code hardcoded timeInForce to GTC, or the SDK/library you are using does not support passing GTD through. Some third-party libraries have had historical issues with serializing goodTillDate, with cases where millisecond timestamps were sent as seconds and rejected. If you are using a wrapper library rather than calling the REST API directly, first check whether it passes this field through unchanged.

After the order expires, its status will change to EXPIRED (expired according to the timeInForce parameter rules), not CANCELED (canceled by the user). Seeing EXPIRED in the order history or query endpoint means the GTD mechanism worked as expected. If your strategy needs to distinguish between "I canceled it myself" and "it expired automatically", this status difference is the basis for that judgment.

If your order did not expire on time

First check the order status. If the status is still NEW, it means GTD was not correctly applied. Go back and check the original parameters of your order request: is timeInForce really GTD, does goodTillDate meet the lower and upper limits, and was the timestamp unit mishandled by your code. Second, the official documentation mentions that "in extreme market conditions, there may be some delay in the automatic cancellation of orders with timeInForce GTD". That means if the status does not change immediately at the set time, it is not necessarily a configuration error on your part. But if it still has not changed after a reasonable amount of time, you need to troubleshoot it as a parameter issue. If the order status shows EXPIRED but the time does not match your expectation, check whether the timestamp was truncated to the whole second, or whether there is a time difference between your server and Binance's servers.