I am creating a portfolio tracker for myself using react. When I am using allOrders API to the order history of a symbol, I am getting different response each time with new latest trades not showing up in the response most of the times. Did anyone face same problem ?
I feel this is happening for me, too. In my case it happens when using âmyTradesâ endpoint. I get different number of trades on a given pair when issuing the same request.
Iâm experiencing the same with the Futures endpoints, and I canât see how Binance thinks this is acceptable.
This post needs more upvotes.
Hi. This is a known issue that tends to happen during the trading spike. Your API request may occasionally hit the DB server which has not yet completed the data syncing process.
@ishuen Does this mean that when a order or trade is executed this order or trade history data is not always available instantly when calling âGET /allOrdersâ or âGET /myTradesâ? What is the maximum latency in seconds for this âdata synchronization processâ?
The trades/orders Iâm after have long been filled already⌠for weeks now; theyâre not new or active. I guess they would have been in the DB server for a long time. For this particular pair, one trade is pending. No trades happened lately.
Does the overall platform trading activity impact the DB server queries?
FWIW, I think similar is happening when requesting /api/v3/myTrades (also reported in another topic).
I donât think the latency is bounded, otherwise theyâd have to reject new orders and lose profit on fees. From experience it might take minutes under extreme loads (although those could have been bugs that were later fixed, who knows). I would really recommend using the websocket interface, it seems to be much more stable and Iâve never seen event broadcast latencies higher than several seconds. However, be careful to follow recommendations on keeping the connection alive: Avoiding/Detecting stale websocket (user data stream) connections
They also have âData sourceâ field listed under many API methods in the documentation, you can study it to get better understanding of what latencies and inconsistencies to expect from which method.
As a general thought, for any kind of time-sensitive trading logic, the websocket is a must. For any other case, those latencies shouldnât really matter.
1 Like
It does not make sense to me. My orders are not new anymore. Theyâre at least two weeks older. So I donât believe that itâs a sync problem. Also, calling the API repeatedly, does return all the orders in some calls.
This is completely unacceptable. You canât even guarantee a reliable representation of the userâs orders state? And you donât even mention this in the documentation? Money will be lost by people using this API.
Why should the websocket interface has more up-to-date data than the REST-Interface? According to @ishuen, âthe DB server which has not yet completed the data syncing processâ provides the same data to both REST or websocket endpoints. So it should be not matter which one to choose. And if so, then it should be explicitly communicated to the end user of the API because the end user expects that when calling an endpoint (for example, GET /myTrades), then binance respond with (already up-to-date) myTrades. If this is not the case, then itâs a bug for me.
1 Like
He didnât state that data syncing process provides the data to both REST or websocket. Docs donât mention the data source for websocket data, my assumption is that it comes directly from order matching engine or âfrom memoryâ as there is no need to write data to DB before broadcasting the event. @ishuen, can you clarify where user stream data comes from, please? Would be great to have that in the docs.
2 Likes
@dino I use the Rest-API and call it every minute to sync my trades. As I refresh only every minute, I think, for my use case, it does not make sense to use the user data stream, or?
the DB server which has not yet completed the data syncing process
How long can the maximum data synchronization delay take? Would be nice to include such information within the dedicated Rest-API-Endpoint.
@ts-00 Donât have a defined max delay time as this value can not be guaranteed.
Always best to use the user data websocket to avoid not getting the update info.
Would be nice to add the information to the official docmentation to those REST-API Enpoints which can return stale or missing data because without this information, the user assumes that the returned data is always up-to-date.
Hi,
I have very simillar issue but on historical orders.
When requesting data from â/api/v3/allOrdersâ endpoint,. sometimes this endpoint doesnât return any CANCELED order, only the FILLED/WAITING.
When I call this request multiple times in a row (via postman, same request), sometimes I got canceled and sometime not.
This canceled order is 12month old so I believe this is not the case of not-synced DB.
Here is a link to screencast with the behavior: https://www.dropbox.com/s/92jzbabojn9gp1s/2021-07-29_16-38-00.mp4?dl=0
Is there anything I can do to check that I received all correct data? Or is there any parameter to request all data including CANCELED?
Would be nice to include this information in the official documentation for those REST-API Endpoints which can return stale or missing data otherwise the user is not aware of that and assumes always up-to-date data.