/api/v3/allOrders is giving different response everytime

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.

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”?

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

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.

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.

@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.

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.

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.


user data stream has the data from matching system directly. @Artur_Brugeman

It seems to be there https://binance-docs.github.io/apidocs/spot/en/#data-sources

1 Like