Does anybody actually use API-NG yet?

[rphi6876]

Just wondering if anybody has made the leap yet to use only API-NG for a bot?

I started looking at rolling over to NG but find so many issues it seems not worthwhile anytime soon.

Firstly, the latency is significantly higher on API-NG.

Secondly, I have also found the placeOrders function super buggy,
For example for the placeExecutionReport I get an errorCode of
ERROR_IN_MATCHER: "The matcher is not healthy". What does that even mean? Yet when I drill down to the placeInstructionReport I actually find the order was placed,

On other occassions I get the error
INVALID_BET_SIZE: "bet size is invalid for your currency or your regulator" for the placeInstructionReport, yet the order was of a valid size and was actually placed.

Thirdly, if I need to green up using an undersized bet I could use the workaround of updating an order, a feature not available on the API-NG, so I cant green up anymore.


Lastly, I mentioned the serious flaw about not knowing what time your requests left the betfair server as in this post:
http://forum.bdp.betfair.com/showthread.php?t=2416

I have found all of these serious flaws after only a day or two mucking around, so no doubt there are many more to be discovered. Given this, arguably the API-NG at this stage is nothing more than a toy, hence my curiosity is anybody actually using API_NG apart from just testing?

Betfair please look into the issues mentioned as there are no doubt large improvements required before NG gains any traction.

[betdynamics]

I have also found the placeOrders function super buggy,
For example for the placeExecutionReport I get an errorCode of
ERROR_IN_MATCHER: "The matcher is not healthy". What does that even mean? Yet when I drill down to the placeInstructionReport I actually find the order was placed,

The error code defaults to ERROR_IN_MATCHER as there is no "null" error code. If the status says "SUCCESS" then you can ignore the error code.

On other occassions I get the error
INVALID_BET_SIZE: "bet size is invalid for your currency or your regulator" for the placeInstructionReport, yet the order was of a valid size and was actually placed.

Personally, I have never seen a bet placed when INVALID_BET_SIZE was reported. The solution appears to be to round your bet size before placing it in the placeOrders call.

if I need to green up using an undersized bet I could use the workaround of updating an order, a feature not available on the API-NG, so I cant green up anymore.

This functionality is still there so greening up should not be an issue (place/cancel/replace is what you need to look at)

[rphi6876]

Hi Betdynamics,

I appreciate the reply and enlightening me on some of issues, Do you use API_NG currently instead of the old one?

The error code defaults to ERROR_IN_MATCHER as there is no "null" error code. If the status
says "SUCCESS" then you can ignore the error code.

-seems like an ad hoc solution to work around a clear bug, why not have an error code "MATCHER_WORKING_FINE"

Personally, I have never seen a bet placed when INVALID_BET_SIZE was reported. The solution appears to be to round your bet size before placing it in the placeOrders call.

-If an order is placed in the market, I should not be receiving an error of INVALID_BET_SIZE.

This functionality is still there so greening up should not be an issue (place/cancel/replace is what you need to look at

appreciate the suggestion - I figured the cancelOrdes function might help here as I can cancel some part of the order, but am reluctant to work on all this at present


My other major concern that I have is that the latency in placing bets has huge variance.

Yesterday, I placed 20 bets using the old api, with an average time to place of 420ms (Aus to UK) and max of 480ms and min around 380ms. So a pretty tight range.

Placing the same 20 bets using API_NG had an average of 2000ms. This was primarliy due to the huge right skew on the distribution. my max was close to 10 seconds and min of 700ms. This seems way to inconsitent to use reliably.

I appreciate the feedback, but it seems like there are so many ad hoc workarounds to deal with a buggy product being offered that I have a reluctance to transition across - yet I know I am going to have to at some stage.

[gus]

I've been using API-NG for my own bots (mostly Horse Racing InPlay) since at least January of this year.

I find it more stable than API 6.0 and the latency is less than with API6.0(tho that might be down to better programming on my part).

Only real problem I've ever had was with listClearedOrders being very slow to return results, but that's improved a lot recently and anyway you can work around it.

I'm a UK customer and I don't Bet on the Australian Exchange, and the latency with calls to the AUS exchange would definitely put me off, but it was bad with API6.0 as well, so no change there!

Perhaps your calls from Aus to the UK Exchange are similarly affected, in which case I see your point, but otherwise I definitely find API-NG 'fit for purpose'.

[Aham4y]

"...Lastly, I mentioned the serious flaw about not knowing what time your requests left the betfair server as in this post:
http://forum.bdp.betfair.com/showthread.php?t=2416"

Can anyone please comment on this issue too. The problem is really crucial for many trading indicators. How do you guys order your prices and traded samples without remote timestamp of the data?

Can anyone from Betfair tell us what happened with timestamp?

[bnl]

Just wondering if anybody has made the leap yet to use only API-NG for a bot?

Yes. Shortly after I started a bot with API 6.0
Betfair announced API-NG.
The first bot was in Python and I though this was a nice
project to learn Python.

However, I did not like it, and it did not take long until
I ditched that, re-wrote the thing in Ada using API-NG.
(I'm using Ada everyday in my work, so I'm fluent in that language)
It is quite different compared to API 6.0, but since
I mostly used API-NG, I find it ok.

However, almost every time a new feature is to be commissioned, something breaks, and it is rolled backed, and scheduled for a retry. And that causes some disturbance most of the time.

Is the bot profitable. Yes it is. No big money, but
positive figures. But that is mostly trading strategy more than
API.

Looking into my bet-database I see that the first real bet
was made 2013-11-17.



/Björn

[snowmoneky]

I've just migrated and think it's much better than the old API. I'm with you on the performance, it does feel slower but I can't quantify that. I've had few problems with it, mostly down to me not reading the docs properly. If your bot is written in java feel free to take a look at my implementation at https://github.com/npomfret/meeno . It's by no means finished but I've implemented most of the API, and I have it working in a production system. Feel free to clone it