Order Timed Out: Check IDs Before Trying Again
Keep request identity and an unknown outcome visible when a response is missing. Learn why a client ID is not a universal permanent retry guarantee.
Separate no response from a confirmed failure
A missing response leaves a gap in your evidence. It does not, by itself, show that an order was rejected or never reached the venue. Keep that distinction visible before interpreting a repeat attempt. An unknown outcome deserves its own state in a journal, separate from confirmed rejection, confirmed execution or confirmed cancellation associated with a specific order identity.
Keep exchange order ID and client order ID distinct
A client order ID is an identifier supplied on the client side; an exchange order ID identifies the order in the venue response. Preserve both when available, together with instrument and request time. Treat them as text so that formatting does not change their characters. A familiar-looking number without its venue and product context is a weak basis for matching records.
Preserve the identity already associated with the request
Identity reuse rules are specific to the documented contract. Binance describes uniqueness among open orders and permits reuse after a previous order is FILLED under its rules. That is different from a permanent guarantee that every repeated request is the same action. The checklist therefore records the original identity and known outcome rather than assuming that a repeated identifier makes a retry harmless.
Review saved order-state evidence before interpreting a retry
A later saved order-state or own execution record can resolve some of the uncertainty. Match its identifier to the original request before connecting the two events. Preserve the evidence reference and when it was observed. If the available record belongs to another order or only describes public market activity, it does not settle what happened to your own original request.
Record unknown, confirmed and unresolved outcomes
The example illustrates a missing response followed by a confirmed fill record for the same identity. The worksheet helps preserve that trail without constructing a network retry procedure. Use the CSV to link identities, response state and later evidence, and the TXT to review unresolved details. No live query, order submission, authentication step or automatic account connection is performed here.
Documented venue distinctions
These statements apply to the named provider and documented product. They do not imply identical rules elsewhere.
- Binance -1007 TIMEOUT reports an unknown sending or execution outcome; it does not prove failure. Official reference.
- Binance Spot client-order IDs are constrained among open orders and may be reused after FILLED under its documented rules. Official reference.
- Binance order-state query accepts the documented exchange or client identifiers and returns state and executed quantity. Official reference.
Hypothetical case
Hypothetical client ID demo-order-001 has a missing response. A later own status record says FILLED. The worksheet links the same identity to that evidence; it does not assume that another submission would be harmless.
Six questions for your record
- What request identifier was saved?
- Was an exchange order ID received?
- Is the outcome confirmed or unknown?
- What existing event or status record refers to that identity?
- Could a repeat be a separate order under this venue rule?
- What remains unresolved in the record?
Keep your own record
The CSV contains column headings only. The TXT contains the review questions and blank note spaces. Keep original evidence separately, preserve identifiers as text and leave missing facts unknown. Neither file sends data or performs an account check.