Get odds data with proper information

[Miriam]

Hi everyone, I'm wondering what's the best way to get odds data of any football event.
With listMarketBook I'm able to get an object array with this kind of structure eacth, but I'm wondering how can I get the name of the selection instead of the selctionId or if there is a way to get the name through the selectionId.

{
selectionId: 58805,
handicap: 0,
status: 'ACTIVE',
lastPriceTraded: 3.75,
totalMatched: 0,
ex: {
availableToBack: [Array],
availableToLay: [Array],
tradedVolume: []
}
}

Thanks in advance!

[jabe]

Anyone setting off on this voyage should look at all the data returned by all calls to see what is returned and how all the data is related. If you had written a system to facilitate betting on a website, what data would need to exist? How would the data be connected? What would make sense?


For each Event there is a number of Markets.

For each Market there is a MarketCatalogue which contains information which should be regarded as fixed.

For each Market / MarketCatalogue there is a MarketBook which contains data that is likely to change.


Selection names are fixed, although some selections may become non-runners.

Hence the selection names should be in the MarkeCatalogue data.


The MarketCatalogue data includes an array of items of class RunnerCatalog.

RunnerCatalog should contain fixed data for each runner. There is no need to store the runnerName anywhere else. Ids are used to connect data.

It contains a piece of data called runnerName and another called selectionId.

[pwebtech]

the call to listMarketCatalogue needs a MarketProjection with a RUNNER_DESCRIPTION value https://docs.developer.betfair.com/d...arketCatalogue

[Miriam]

With MarkeCatalogue I get data regarding the runners that includes selectionId and runnerName, but no info regarding price. Then I have to store these info, make a call passing the marketId to listMarketBook, get back just selectionId, price and size so I have to compare those selectionId with the ones stored to get a simply info such as runnerName. Am I missing something or these API are bad structure or am I not enough good to use them properly?
Such a nightmare.

My goal is to get odds data (price and name) about some football match, what am I doing wrong? Why is it not easy to get this? Thank you!

[pwebtech]

yes i'd make two calls and join the data on selectionID, and yes given that the selectionID/name won't change, you could store that data and just call for the price/volume as needed? so as far as i can tell there's no way of getting this info in one go!

[jabe]

With MarkeCatalogue I get data regarding the runners that includes selectionId and runnerName, but no info regarding price. Then I have to store these info, make a call passing the marketId to listMarketBook, get back just selectionId, price and size so I have to compare those selectionId with the ones stored to get a simply info such as runnerName. Am I missing something or these API are bad structure or am I not enough good to use them properly?
Such a nightmare.

My goal is to get odds data (price and name) about some football match, what am I doing wrong? Why is it not easy to get this? Thank you!

IT standard is to use ids. Names of people, businesses, even countries cannot be guaranteed to remain the same. I spent a lot of years in IT and I think they did an excellent job with the data structure in the API.

The design of the data in the API minimises the amount of data retrieved in calls, making calls quicker. listMarketBook shouldn't need to bring you data you already have, even at the expense of a little extra processing. If your program is monitoring odds in a particular market, its MarketBook could be requested dozens or even hundreds of times, so why would you want it to keep returning data you only need to get once? Not efficient. A coded structure keyed on selectionId is all it takes to get the runnerName - almost no coding.

That said, the API is very complicated and I always suggest beginners create classes for every set of data they're likely to use so they know where everything is, if and when they need it Yours is not a simple task (and nor is mine), but stick with it, and hopefully you'll get where you want to be.

Do search the forum or ask a question when you get stuck, as you did. There's lots of knowledge around here.