Further to my earlier post and following further investigation.
Customers should avoid making calls to listClearedOrders providing only eventIds or only sportIds, along with any roll-up GroupBy lower than MARKET, as this is likely to result in slow response times.
If you need to drill down, you should initially make a call for roll up by EVENT within a sport. Then call for roll up by MARKET within the event. Then finally ask for the bets within the market.
We are looking to make performance improvements to listClearedOrders and will update this advice as soon as these improvements have been put in place.
The calls I currently make to listClearedOrders have only a List of betIds and I ask for them to be grouped by BET (which I suppose is a bit redundant).
The request is always for clearedOrders for one market only, so would it speed things up if I also specifed the marketId (as a List)?
A performance fix was released this morning to address the reported issues with listClearedOrders.
However, please let us know if you continue to experience issues. We recommend that any request for a specific eventId is accompanied by the required eventTypeId (sport).
The calls I currently make to listClearedOrders have only a List of betIds and I ask for them to be grouped by BET (which I suppose is a bit redundant).
The request is always for clearedOrders for one market only, so would it speed things up if I also specified the marketId (as a List)?
Hi gus,
The changes made this morning should fix the issue you've been experiencing so far.
Yep, glad to report that all of my calls to listClearedOrders yesterday afternoon/evening were getting a response, and listClearedOrders was returning my bet results within 2-4 minutes of a WINNER or LOSER being returned by listMarketBook.
Problems again with listClearedOrders for soccer events, like last weekend. Is there any information about what the problem is or how to work around it?
listClearedOrders response contain not all events. Now, for example, I have today 200+ settled markets, but listClearedOrders returns only 380 bets on 98 markets.
Hi all this is my first post in this forum and i wish to share some personal considerations about the new api protocol.
I started the porting (from API 6.0 to API_NG) of my application two weeks ago and now (working all days) i nearly finished it.
The new protocol is really different from the older one and is not possible to make a "flat" porting. Number,types of parameters and responses are completely changed and some logics of the application necessarily need to be rewritten.
However the work went fast, thanks to a much more structured logic of the new api: less commands with more functionalities.
The possibility to request more than one market is the big news and has increased a lot the performance of my application. This alone justifies the effort. Besides there is a much more easy way to place bet with a size under the limit (two sequential commands instead of three with a waiting state). Besides the interactive login is good to give greater security to the customers and to be less "trusty" (and for an unknow vendor is a good thing).
I can definitely say that you have done a very nice work, with the unique exception of one command: listClearedOrders.
This command is very important because finalizes the result of an event giving each bet its definitive P&L, and my application tracks them.
Well, this command has a mandatory parameter that is betStatus (VOIDED, LAPSED, SETTLED, CANCELLED); the problem is that i cannot know in advance the status of a bet leaved unmatched on a market before its closure.
I know You have designed the command in this way to reduce the server effort, but i need anyway to make 4 requests instead of only one.
Furthermore this command have a lot of filter parameters (date range, events, event types, etc..), perhaps they are usefull for applications without a database and that doesn't tracks the bet placed, but in my case i know the ID of each bet placed and i can make the request using the unique bet keys. This command is not reliable and fast like the others, sometime it goes in timeout or gives false answers.
So please consider the hypothesis to implement a listClearedOrders without so much filters (only betIds or marketIds) that returns also the status of the bets.
HI can definitely say that you have done a very nice work, with the unique exception of one command: listClearedOrders.
This command is very important because finalizes the result of an event giving each bet its definitive P&L, and my application tracks them.
I do not understand the importance of listClearedOrders. I even do not bother to invoke it. listMarkeBook has runners array, each runner has match property that has array of fully/partially matched bets (orders if you prefer).
I can calculate P&L from the data easily. To finalize the result of market only matched bets are of interest, I really do not care of VOIDED, LAPSED, UNMATCHED or LOST_FOREVER statuses. I recalculate the P&L after each listMarketBook, not on market close, the calculation is much cheaper than invoking listClearedOrders or listMarketProfitAndLoss (and I have 8 CPU cores that I cannot load reasonably)
Algotrader thanks for the answer, i'm searching for an alternative to listClearedOrders. My problem is when there are unmatched bets in the market before its closure: i have to know if they have been matched/partial matched (for example by by SP reconciliation).
And also i have to know if the P&L i have calculated when the market was open is the same to the P&L calculated by betfair after the closure. There are few cases, in my experience, of difference, for example: dead heat, runner retired few seconds before the start, and others i don't remember..
How do you treat these cases?
Comment