The Next Sports Exchange API is Coming

[BetfairDeveloperProgram]

Betfair is hard at work on the next version of the Betfair Sports Exchange API. It’s been a long time since we made any significant changes to the API and we know there is lots of pent up demand for some new features, etc.

As you may know, Betfair has been busy re-building the underlying infrastructure of the Sports Exchange. The Betfair.com website has had a facelift and is now powered by a new set of internal services. The next version of the Betfair Sports Exchange API is going to be built on top of these new services.

The goals for the new API are:

• Simple things should be simple, complex things should be possible
• The best way to build an interface to the Exchange
• Anything you can do in a Betfair built interface can be built on the API
• Build a modern web API (HTTP/JSON)
• Fix the missing features in the API (compared to the Website)
• Satisfy some long-standing feature requests
• Access to the same data
• Access to the same products (Sports Exchange, Sportsbook, etc)
• Easy to use and easy to learn

There are a number of specific enhancements and new features planned for the API based on the above goals, but we wanted to highlight three today:

1. Virtual Prices. The new API will return the same price data as the website.
   
2. No more SOAP. The new API is RPC/JSON. You can request data with an HTTP GET to a url like "api.betfair.com/v001/listMarkets/ and get a response like:
   
   

   ...
       "availableToBack" : [
                         {
                           "price" : 21,
                           "size" : 4.06
                         },
                         {
                           "price" : 17.5,
                           "size" : 3.62
                         },
                         {
                           "price" : 1.05,
                           "size" : 3.68
                         }

3. Easier to get the data you need. The new API combines public market data (like market prices) with private market data (i.e., you're matched and unmatched bet status) in a single response.

We don’t have a definitive release date for the new API. However, we are hoping to begin letting people kick the tyres sometime in the next few months. We will be posting more information about the upcoming API when we’re closer to a release date, including documentation and sample code.

Let us know what you think of these changes! Please post any comments here in the BDP Forum.

[Toy]

Excellent, can't wait!

[AlgoTrader]

The best thing I ever saw in this forum! Guys you do an exellent job! JSON is much simpler and shorter, so we may say goodbye to many XML complexities!

[AlgoTrader]

Now, as my euphoria is calming down, may I ask you several questions:

1) Will the old API work in parallel with the new one or will be discontinued after a transition period?

2) What will happen to throttling of the FreeAPI with the new API?

3) How about request data charges of both Free and Paid API with the new API?

4) Will you provide specs to developers so that they can update products early?

I aware that you may not have answers to all those questions

[MarkL]

Hi,

I'll try to answer as best I can...

1) Will the old API work in parallel with the new one or will be discontinued after a transition period?

Yes, we expect API 6 to be supported for at least 18 months after the official release of the next API version. As there will be a transition from SOAP to JSON, we expect some people will need a while to move to the new version.

2) What will happen to throttling of the FreeAPI with the new API?
3) How about request data charges of both Free and Paid API with the new API?

There is likely to continue to be some for of throttling. There will almost certainly be different API subscription levels, as there are currently. However, I can't say exactly what they will be or if they will be different to the current levels.

For the Data Request Charge, the primary purpose of the charge is to manage load levels. The new API will have different load limits, etc, so I expect we will revisit the data request charge.

Also, as the new API will let you request more data in a single request, the current DRC structure may not make sense.

4) Will you provide specs to developers so that they can update products early?

Most definitely. Also, rather than wait until we have a complete API, we are planning on releasing it in stages. I expect you'll be to find markets and query prices first, while still using API 6 to log in, for example.

I aware that you may not have answers to all those questions

Thanks. We don't, but we're going to do our best to be as transparent as possible.

Cheers,
Mark

[AlgoTrader]

Mark, thanks for the answers. I will support the new API in days after it goes publicly available (JSON is perfect format for serializing and deserializing objects).

More questions: will we say goodbye to "Compressed" methods? There are four compressed methods for now getAllMarkets, getMarketPricesCompressed, getCompleteMarketPricesCompressed and getMarketTradedVolumeCompressed.

JSON also may have some sort of "compression", for example

[{
"price": 21,
"size": 4.06
},
{
"price": 17.5,
"size": 3.62
},
{
"price": 1.05,
"size": 3.68
}]

May be coded like

[
[21, 4.06],
[17.5, 3.62],
[1.05, 3.68]
]

Hopefully, there will be no more "compression" and "smart encodings" like in my second example.

In SOAP we had *huge* overhead: open/close tag duplication, xsi:type's, ugly arrays encodings and too much of namespaces sex. The complex "compression" was invented to fight SOAP verbosity, I see no reasons to continue the battle any more.

[MarkL]

In SOAP we had *huge* overhead: open/close tag duplication, xsi:type's, ugly arrays encodings and too much of namespaces sex. The complex "compression" was invented to fight SOAP verbosity, I see no reasons to continue the battle any more.

We don't have any plans to offer anything other than standard JSON responses, but we'll look into the "smart encoding" you mentioned.

As for the "compressed" responses of API 6, no I'm pretty confident we won't continue with that for the next API.

[AlgoTrader]

Mark, thanks. The last question, will we see some standard JSON RPC protocol or there will be some proprietary solution?

The only JSON RPC protocol I know is JSONRPC (http://www.jsonrpc.org/specification). It's specification is just two A4 pages, it's the most perfect RPC spec I ever saw.

The keepAlive example will be like this:

request:

{
    "jsonrpc" : "2.0",
    "id": 1234567,
    "method": "keepAlive",
    "params": {
        "header": {
            "sessionToken": "PKdvAW+ruIAg0s769DeM+vxY=",
            "clientStamp": null
        }
    }
}

response:

{
    "jsonrpc" : "2.0",
    "id": 1234567,
    "result": {
        "header": {
            "errorCode": "OK",
            "sessionToken": "PKdvAW+ruIAg0s769DeM+vxY=",
            "minorErrorCode": null,
            "timestamp": 1231456803125
        },
        "minorErrorCode": null
    }
}

JSON is a huge step forward comparing SOAP+XML, but JSONRPC would be perfect.

[MarkL]

JSON is a huge step forward comparing SOAP+XML, but JSONRPC would be perfect.

Well, then prepare for perfection.

We will support a mixture of transports, so you can make a call like /listMarkets?marketId=1.22100 and get back JSON, or make the same call using JSON-RPC and get back a JSON-RPC response.

[eddie93]

Is there any possibility in advance of this new API going live that you could put up a testing server that gives back example data ? i.e. data that's of the correct intended format but not linked to the actual live exchange.

[wotsisname]

About time, too. I suggested this over 2 years ago: http://forum.bdp.betfair.com/showthread.php?t=896. Surely I must be due some kind of suggestion fee? lol.

Apart from the obvious benefits of using JSON formatted data, I think the "universal" data is a major step forward. As I said in the above linked thread, the website returns more information per packet and includes things like form figures and jockey names, which the API doesn't. This new format will reduce Betfairs' server maintenance, significantly reduce data costs, and more importantly satisfy all customers by taking away all advantages/disadvantages between the various http platforms.

Will the new format also allow for multiple or combined responses? Say for instance we have a market id and want to read market description, runner names and prices, that is currently at least 2 API calls. Returning it in one makes a lot of sense.

[AlgoTrader]

The current API has lots of legacy that makes problems to both its users and Betfair.

For example, getMarket is just 6pm, so I use getMarketProfitAndLoss to get selectionIds and selectionNames. On the other hand, I rarely use getMarketProfitAndLoss for getting balances to avoid request charges and inconsistency with MUBets, I calculate ifWins from getMUBets.

My pattern is that I use getCompleteMarketPricesCompressed, getMUBets and sometimes getMarketTradedVolumeCompressed to refresh a single market.

I use lots of "obsolete" calls to overcome throttling. For example, I use both CompletePrices and Prices to increase prices rate from 60 to 120. I use getCurrentBets to increase bets rate from 60 to 90 (two getCurrentBets replace a single getMUBets).

Many current calls are very inconvenient. In many cases, I have to store request to parse response correctly. For example getMarketTradedVolume has no marketId in response - no problem, we have request saved.

Hopefully, we can provide feedback and participate in API development

[AlgoTrader]

I agree with wotsisname, we have to issue too much of calls. For example getMarketProfitAndLoss is just called to get runner balances, two digits in my case, pretty calculable from getMUBets.

There are lots of tricks. getCompleteMarketPricesCompressed has no marketStatus field, but... there is calculation method. OK means ACTIVE, EVENT_SUSPENDED means SUSPENDED and EVENT_CLOSED means CLOSED. getMarketPricesCompressed on the other hand has normal marketStatus field. getCompleteMarketPricesCompressed and getMarketPricesCompressed has very different formats, I need two different handlers for the almost the same information. The same for tradedVolume

The most strange APIs are certainly placeBets/updateBets/cancelBets. placeBets require marketId for each bet, but market for all the bets should be the same. placeBets and updateBets return strange errorCode replicated for all the input betlist. updateBets even more fun! for example I placed bet lay $100@1,01. Then I can call updateBets, put oldSize=$5000 and newSize $6000, there will be another bet placed for $1000. I strongly avoid updateBets for increasing bet sizes (just placeBets), updateBets is only for canceling. I know several more tricks.

I use lots of calls to overcome throttling, lots of calls to get missing info from other calls - it makes unnecessary load to Betfair.

[MarkL]

My pattern is that I use getCompleteMarketPricesCompressed, getMUBets and sometimes getMarketTradedVolumeCompressed to refresh a single market.

The new API will allow you to make a request that retrieves the complete market depth, your current position (i.e., getMUBets), and the traded volume of the market in a single response, for 1 or more markets.

Hopefully, we can provide feedback and participate in API development

Well, that's the point of opening this discussion up on the forum.

[MarkL]

Will the new format also allow for multiple or combined responses? Say for instance we have a market id and want to read market description, runner names and prices, that is currently at least 2 API calls. Returning it in one makes a lot of sense.

Yes, and more. We also expect you'll be able to get your current bet position as well.