Shortly after I placed an order, this endpoint
GET /api/v3/order
returns
{"code":-2013,"msg":"Order does not exist."}
But I’m pretty sure I just created an order.
If the order is successfully placed, and the order number is returned. But this order information cannot be found by GET /api/v3/order.
Binance’s ordering process is hitting the matching engine first, and then the order information will be sent to downstream channels, including the persistence layer, Websocket server, etc. The biggest advantage of this design is that the entire trading system is very scalable and will not be limited by common restrictions, like IO, etc.
This endpoint GET /api/v3/order takes data from the persistence layer . According to the above information, there is a time gap from the matching engine to the final persistence. This time difference may be over 10 seconds at the moment when the market price fluctuates greatly. Our system is constantly optimised to keep the delay within 1 second.
In order to ensure that users can get the latest updates of the order as soon as possible, we recommend that users get notices through the Websocket connection. For example, after a user places an order, the websocket server will push the complete order data set to the user through the event type of executionReport in the fastest time.
3 Likes
@dino isnt it possible to introduce new order stati, like other exchanges have?
I call them “submitted” and “pendingcanel”. binance already has “PENDING_CANCEL”, but it says “unused” in documentation.
Submitted would mean "we received your request, but our engine did not process (match or place) your order yet. Pendingcancel works the same “we received your cancel request, but order is not yet cancelled”.
To receive such a status would be MUCH more helpful than a “not found”.
1 Like
It doesn’t work in Binance. As mentioned above, the GET /api/v3/order looks up the record from persistence layer.
Even we introduce the submitted status, but before it reaches the DB, the endpoint can still receive the same error “Order does not exist”.
1 Like
@dino to me, this is a bug in the API design.
A correct lambda architecture would use the order information from the persistence layer, or alternatively, if it’s not yet been persisted, would be pulled from a caching layer, where the uptodate order information is kept (binance has to keep the data “someplace” - otherwise it would not know what to persist afterwards).
Therefore, i’d like to request that this is changed to allow querying the order immediatley also via REST endpoints.
Not returning this data right away can be seen as misleading - and i’m sure on a normal, regulated exchange this could be seen as misleading the market partecipants about their own orders (especially since the same delay can also happen when a limit order is filled).
Until the above is implemented, what is the worst delay to be expected?
I’ve seen reports where you said you try to keep it <1s - but in peak times it can be 10s - but i’ve seen more than 30s just last night - so please - what is the MAXIMUM that this delay can take.
Thanks
4 Likes
@xmatthias Thanks for your feedback. There is no bug here. We think matching the orders as quick as possible is more critical than persistent the order status. And we publish the order status and account information on the first time when it’s available.
Thinking of “Websocket first” when integrating with our API, you will find out it’s easy to trade on us, and very fast. 
1 Like
I think, the exchange data is basically streaming data (a constant flow of data streaming through the systems). A very common, and best practice approach for this is the lambda architecture, where you get the data from persistence (if possible) - and from the “non-persistent” layer if it’s not yet in persistence.
If done properly, this will have no impact on the matching engine, as this runs “on the side” (and the order must be cached anyway).
However, please answer the 2nd part of my question, too - what is the maximum delay that we can experience between placing an order, and seeing the order in the GET order REST endpoint?
2 Likes
Sorry, there is no specific maximum number for the delay.
@dino I think binance must be able to provide a time at which point it’s able to guarantee that the GET /api/v3/order end point gives correct data. without this information, it could be 10 seconds, or 10 minutes.
Whenever querying this endpoint, we cannot rely on this having accurate data (the API could report an order as open and unfilled, while in reality it is already filled).
You can point to the websocket API for sure - but this endpoint is giving false, missleading information!
Also, the API documentation should clearly point out that this endpoint is not reliable, and can provide info delayed by up to X amount of time.
I can open a new request for this if you want / need … but this information is crucial for all users of the binance API, and it seems like Binance seems to try and push this API design mistake “under the rug”.
6 Likes
I do get this error for limit order created 25 days ago. What does it mean?
2 Likes
please see the explanation above, thanks