Migrating to v3

When we first launched our API it was for a small group of customers who wanted a simple way to access our data without too many hoops and hurdles. As a result, the first version was created based off of user requests and not from a future looking / generalizable approach. Over the past year, we have realized the v2 of our API could only take us so far, as a result our engineers decided to rethink the API from the ground up to ensure that it will be simpler and work better for our customers.

With the introduction of v3, we are also introducing a better developer hub which will hopefully make for a better developer experience.

Major Pain Points from v2

When games would get rescheduled, they would show up as 2 different games, which caused issues with bets and keeping track of statuses.
Our id fields, query parameters, and data responses did not have any consistent shapes, which meant every endpoint would need custom parsing logic.

Whats Changed?

Query Params

Please double check your query params when moving to v3, we tried to standardize our parameters with v3, so what might have been sportsbooks=in v2 will be sportsbook=and so on.

Deprecating Games

We are removing the concept of a game and a schedule and merging these together into a single new entity called a fixture. You will notice that a fixture will have a id field and a game_id field, you can use this game_id field to map existing games to this new model. It also allows for the ability to slowly transition between v2 and v3.

/games -> /fixtures/active

Since we are adding more sports and leagues every day, to ensure our API is still performing with low latency responses. This endpoint will now be paginated.

Stream

The /stream endpoints will now require you to pass a sport in as part of the url. For example, api/v3/stream/basketball/odds.