API Roadmap Survey

[BetfairDeveloperProgram]

Which feature would you like to see provided via the Betfair API?

[MarkoB]

Virtual wallets ASAP please.

[BetfairDeveloperProgram]

Thanks MarkoB, are you specifically referring to a test bed style system?

[HarryHindsight]

Having two factor authentication optional for log in .

Horse Racing GPS feed ;
In Play betting is a point of difference that Betfair can offer their clients. Having applications that can level the playing field against on track players can only be good.

[tarb]

I have a couple little pain points,

Can we have market name and selection names returned in the stream? Having to make repeated calls out to listMarketCatalogue just to grab the names is annoying. This can leave UI's in an incomplete state when the stream pushes new markets and you must then request the names from lmc - its also not an insignificant problem to solve if you want to batch a request for multiple markets at the same time and have it be fault tolerant to network errors. Adding the names to the MarketDefinition and RunnerDefinition would be a very insignificant increase in payload size. But still if this was a major concern then a field in the MarketDataFilter could be used to control this behavior and allow latency sensitive applications to keep the current behavior. Its also seems worth noting that the pro historic data already does exactly this, with the MarketDefinition and RunnerDefinition both having a name field but otherwise being identical to the stream data.

With the stream having a market limit of 200 markets it can be hard to (or sometimes impossible) to subscribe to a whole country/eventTypeID, this mainly happens when a few days markets are loaded in advance (AU 4339 is bad for this). I would love to have a filter which controls how far out to return markets, ie only return markets whose start time is in the next 24 hours. A bump to the default 200 market limit would also be nice.

Cheers

[RedDeadFred]

+1 for runner names in Stream API.

Another thing - the runner IDs are at the end of the JSON rc objects, so I need to temporarily store all of the data before the ID, then copy it into my model once I get the ID. If the runner ID was at the start of the JSON object I could stream the data directly into the right model.

Likewise for the img field, which is the last field, even though it determines how the preceding data should be handled.

Having these fields at the start of the JSON objects would make client code so much simpler.

[LiamP]

+1 for runner names in Stream API.

Another thing - the runner IDs are at the end of the JSON rc objects, so I need to temporarily store all of the data before the ID, then copy it into my model once I get the ID. If the runner ID was at the start of the JSON object I could stream the data directly into the right model.

Likewise for the img field, which is the last field, even though it determines how the preceding data should be handled.

Having these fields at the start of the JSON objects would make client code so much simpler.

Intrigued by this, why does the position matter? Just loop the market changes in rc, select the [‘id’] and do what you want with it, same with img.

[RedDeadFred]

Intrigued by this, why does the position matter? Just loop the market changes in rc, select the [‘id’] and do what you want with it, same with img.

I should've clarified - if using a non-streaming parser which will load the entire message into an intermediate data structure, and you don't mind doing hash-table lookups while accessing fields, there is no issue.

If using a streaming parser, and if the id and img field were at the start, you could start processing the message before it has even been completely received from the network, avoid extra memory copy and avoid using hash-tables or loops to access fields.

[LetsGo]

I would like to have access to the "Cash Out" option from the api.

[bfexplorer]

Football meta data are already offered by web api, well not documented but accessible, therefore I would really like to see implementation of Graphs API, what you actually already promised to implement.

To the football meta data, I have got following question:

How you manage VAR decisions on top leagues in Europe they already use it in couple leagues, I watched El Clasico yesterday and VAR was used .

You should suspended market till VAR decision is not known, that did not happen in many matches in last days, I noticed such situation when testing some football strategy:

http://bfexplorer.net/Community/BlogContent/382

on SPAL - Frosinone match, at 32 minute of the match it was reported 0 - 1, then later in next minute the score was fixed to the right one: 0 - 0.

[Mike123]

It would be interesting if it would be possible to add a label to a bet while placing a bet (for example A or B etc).

After this the label should be visible in the bet history for every bet. This would make it easier to link bettingstrategies to results.

[bfexplorer]

It would be interesting if it would be possible to add a label to a bet while placing a bet (for example A or B etc).

After this the label should be visible in the bet history for every bet. This would make it easier to link bettingstrategies to results.

That is already implemented, read api doc.

[jptrader]

I suggest that you extend RunnerStatus (https://docs.developer.betfair.com/d...s-RunnerStatus) to include more information about the final status of a runner. Right now, it does not reflect the statuses that can be obtained on e.g. Football Asian Handicap /Draw No Bet/ Goal Lines markets etc, where a runner can have a final status of not just Winner or Loser, but also Void, HalfWinHalfVoid or HalfLoseHalfVoid. This information is currently unavailable from the API, and users must know the final score (also still unavailable from the API) to track this.

[drazor25]

Voted Other - Would like to use my vote to the adding of market and runner names in the Stream API as I also need to make calls to listMarketCatalogue just to get them. In addition there is a lot of very useful runner data in the runnerMetadata returned by listMarketCatalogue (previous form, days since last run, offical rating, weight, etc) that would be good to have as in the stream API. As this information does not change for the life of the market perhaps it could be returned only for images and optional via a flag like it is in listMarketCatalogue.

[LetsGo]

Voted Other - Would like to use my vote to the adding of market and runner names in the Stream API as I also need to make calls to listMarketCatalogue just to get them. In addition there is a lot of very useful runner data in the runnerMetadata returned by listMarketCatalogue (previous form, days since last run, offical rating, weight, etc) that would be good to have as in the stream API. As this information does not change for the life of the market perhaps it could be returned only for images and optional via a flag like it is in listMarketCatalogue.

Absolutely not. Streaming is for data changes upto 20 times or so a second, like the price and amount available.
The horses names ect... are static data and only need to be called once.