I too need this obvious endpoint, its very very weak that it doesn’t exist. Many other exchange apis support it, and the result is pointless hammering of the current endpoint one symbol at a time that slows down getting the data and probably chokes up the endpoint bandwidth.
The websocket is no use if there is no persistent connection to the users running application.
3rd party developers help build Binance’s overall business by providing tools for users to help them trade, So its really poor that this very basic user api endpoint doesn’t work intelligently.
If it was my API I would be embarrassed, frankly, especially since you are on V3 of the api!!
This is getting ridiculous when using a lot of sub-accounts or creating a 3rd party service as others pointed at. With 100+ sub accounts, hundred of thousands of calls are needed to check the history for all symbols for all subs.
I feel like this forum is only for very basic questions and that any feature request is completely ignored
feedback, suggestions are all reviewed and forward to the team if they are reasonable.
For this concern, there are already plenty discussions.
With 100+ sub accounts, client can easily consume all request limits in short time. But with websocket, it can be handy to just subscribe and listen for account changes.
Spot websocket support up to 1024 streams per connection, so you can listen all sub accounts in just one connection to server, without request limit concern, it’s the best practice to get all orders.
Hey Dino, thanks for the reply to this issue. You can see many people have problems with this. The websocket doesn’t allow fetching historical data, so if the users app is off or not on the network, there is no way to use that to get the full info of a users orders and trades without hammering the current endpoint.
In practice, the vast majority of endpoint calls return no results, so it’s hugely inefficient. There are ~1300 symbols and climbing, and any given user might have orders across only a very small percentage of those, yet we have no way of predicting what new symbol they might order on next.
Surely a getAllOrders endpoint should be able to return all orders for that user. If it still has the optional “since” timestamp, fromId and result number limits we could get recent results in one call and all results in a handful of calls for the vast majority of users.
Even if it had a big fat Rate limit like only allowing a few calls per minute it would STILL be far faster and involve less server time and load than the current process.
Please consider escalating this issue, it’s the one deal breaker in an otherwise good API.
I truly believe it can’t be that difficult: you have your account, distinguished by e-mail, and somewhere in their databases there must be some sort of relationship between the account ans the spot orders. Thus, you just need to fetch the associated orders.
I reckon it’s the ONE main deal breaker to efficient use of the API. Rate limit the hell out of it, its still gonna be 100x quicker than doing the one symbol at a time search where the overwhelming majority of calls return zero, always. Less load on the servers as well I expect.
C’mon Binance Devs, feel our pain, I reckon it could be done in one sprint, let’s have it for an Easter Egg. I bet this endpoint exists already within the Binance internal codebase. You just need to expose it with the right structure and limits in place.
Also, please stop trying to side track the issue by saying to use the websocket. The websocket is no solution to apps that are not always connected (ie vast majority of mobile apps)
Frankly, the only reason I can imagine they haven’t implemented it after so long is a business decision, but I’m blowed if I can see how this helps protect their business. I can see no good technical reason blocking this endpoint change.
This is a +1 for C’mon Binance Devs from me. The rational given for it not being possible to do seems faulty.
The relationship in data model for getting an account’s orders must exist somehow already or you couldn’t find them in the first place. If you need to loop through everything by token to access them then there’s serious issues with how your data is structured. It can’t scale that way for one thing, but I’m sure that’s not the case.
You need to give us a sane way to get a history of all the trades made. It’s a basic requirement and I can’t see how it can be all that difficult. Might be easier to just create a new endpoint specifically for this. I think this would be much appreciated by everyone.
I need to create an app which will listen to a master account and if an order placed in the master account, I will do some business as send sms, email, notification, open another order, etc… I can’t find the api that allow me to listen to master account and send me notification if an order take place…. Can any send me this api account/its signature and if u have any sample code.
I see a nice solution that could be to trigger the Historic data delivery
so the delivery would be streamed via the websocket , in that case Binance could deliver in a speed that fits them .
Other benefit in this way we could drop the origital Rest Api call and get all data via socket.
This Rest call could as suggest be including filters “From Id”/"date/Symbol etc.
Any updates here? It would be great to have an API that can provide the full order/trade history. Along with that if a from_id or paginated query is provided, it would make it much easier to update the local copy as well
looks like it’s going to become 2- 3 times more cumbersome, based on the latest announcement. @BNB any chance this process will become leaner? there are quite a bit of steps to do something so common and foundational for each api connection.
in many aspects, the endpoints available are awesome, top notch. However, in a few areas, like this, there seems to be excessive waste of resources for such a common and frequent process, i’m sure you can save plenty of bandwidth/performance (and costs therein) by applying a more efficient (lean) approach. it’s a great api. just trying to provide constructive feedback.
@bomb-on, well, extracting the dribblets from the dust log is fairly simple, but an added step nonetheless. The fun stuff starts when you want to start compiling it all into a single “portfolio,” which (if account has any savings activity) requires further tedious steps, other data is simply not accessible via the available API endpoints. hassle-tastic to say the least.
UPDATE: think about investing some time into proper request-weight management system, otherwise it is now an absolute certainty that you will hit your limit every minute of building your trade history
@Binance… Thx for making things even more complicated by increasing the API weights! Now it’s almost impossible reading the order history.
Having to provide a dedicated symbol is just rubbish from a database perspective. You have to loop through all symbols where you don’t even have a complete list if symbols changed or became inactice for some reason. This results in much higher server load than just returning all orders in one result.
Next problem is that the C# implementations of Binance API do not take the weight of a request into account. So you run into the IP ban for sure…
It really makes me thinking if Binance is the right exchange for me…
Not being able to query the entire trade history without having to specify a symbol is really a KEY feature missing… Websockets are clearly no option at the moment as so many before me have stated.
So far Binance has not explained/given a good reason why they would not implement a way of retrieving the past history for all trades without having to specify a symbol. Seems a bit strange to me considering other major exchanges have that feature.
@dino
What about new api endpoint. GET all coins name where data is present. Cached it. When workflow will be quite easy.
GET all coins with data:
Return: [BTCUSDT, DOTETH,…] Like 100 not 1400 coins mostly.
When fetch only 100 coins using exist end point.
Quite easy to implement for you guys and manage by cache. Using “SET” list.
And response from new endpoint will be quite small no more then (1400*coin name length). No need pagination, no need sorting or filtering.
It will cut requests to 10-30 times from now.
Websocket is not the answer. Connections no stable enough to relay only on this. What if server is down and then you restarting you need to fetch everything again to not miss data as it will affect history in the future.
for C’mon Binance Devs from me. The rational given for it not being possible to do seems faulty.