Everything you need to get you up and running
-
Registration and Login
Takes you through the registration process by way of filling out the registration form, and what happens in order to get approval to use the site
-
Documentation and Terminology
Discusses the terminology used, what App_Id is, what Content Types are available, and the Http verbs in use. It also deals with Status codes and Errors
-
Choosing the right Kindred API for you
Talks about what developers can do with the Kindred APIs, what we at Kindred are hoping they'll build, what kinds of things are possible
Registration and Login
In order to start your journey developing using the Kindred API, you'll need an access id and key to be used in each call you make. This id is unique to you, and you should keep this (and especially the key) secret.
To obtain this id and key, you must fill out a registration form. On the Kindred Developer site, click on the 'Register' link at the top right of the screen and fill in your details.
Fill in as appropriate. Type of partner is likely to be Affiliate; Username, Email Address sohuld be unique to you, and so on. Plesse ensure that at least all the faileds marked with a * are filled in before submitting the form.
Once the form is submitted, our team will review the application and approve it. Email confirmations will be sent to your inbox. Then you are ready to go.
Documentation and Terminology
When using the kindred API, there are a few pieces of information you shouls know to make sucessfull calls. These are listed here.
App_ID/App_Key
This is the authentication method used in Developer Portal. It is used to access the feeds you need for your client. It is known as the App_ID and App_Key Pair. This combines the identity of the application and the secret usage on one token. This pair must be included as parameters in you feeds calls. And example of this would be:
../event/1005328661.json?app_id=02cb2a62&app_key= c865dbd4576bfd35badfc9ed846a83a
The App ID is constant and may or may not be secret. In addition, each application may have 1-n Application Keys (App_Keys). Each Key is associated directly with the App_ID and should be treated as secret.
Http Verbs
We use standard HTTP verbs for our feeds. In fact, this is made very simple in our case as ALL of our feeds support the Http Method GET, and only that. In general, ensure your application supports these verbs.
Status Codes
The API makes use of HTTP status codes as per the HTTP spec. The responses you should expect to recieve are:
Errors
When an error occurs, the response will ususally be an object that includes the status, and a message to help you understand why the error occured. An example would be:
{ "error": { "status": 404, "message": "Nothing found" } }
Content Types
When making calls for feeds, you can decide the content type of the data that will be returned to your application. We offer three content type repsonses:
Json, or JavaScript Object Notation, is a text based and lightweight standard, consisting of attibrute/value pairs and array data types. It's very human readable and is commonly used with JavaScript; the data structures between these are easily interchangable.
Jsonp, or Json Padding can allow the user to use the feeds as a source of data within a piece of JavaScript using callback functions. The user can define an additional parameter in the feed call, named callback which will wrap the repsonse. When used in conjunction with the JavaScript function, the function can take the returned data as an object and oparate on it. Here is an example of the call:
../sportsbook/event/group/1000093190.jsonp?callback=processData
In this example, you'd define a callback function called processData(feedObj) and use feedObj to access the data.
Xml is another text-based format offered, which is widely used in structured documents across the internet.
The Right Kindred API - Sportsbook
The Kindred API Sportsbook offerings are separated into the following sections to help you more easily decide which feed to use in your client.
Event Groups
Event groups are used to organize all events into a tree structure. An event group may contain events or other child event groups. The event group tree has three levels, where most events are located in the lowest third level. The tree structure is a basic instrument for browsing domain model. See the related resources. The event groups are normally (but not always) organized as Sport - Region (country) - League, but there are exceptions where event groups and events are structured in another way in the Kambi domain. Standare structure:
Football
Events
An event corresponds to a single happening that has a set of possible outcomes and for which there are different bet offers. There are two types of events: matches and competitions. A football game is a match, the Football World Cup is a competition. In addition to sports events it is also possible to place bets for political and other public events like president elections or Eurovision Song Contest.
Bet Offers
A bet offer belongs to one specific event. Example of a bet offer is "Who will win?" or "Over/Under 2.5 goals during first half". Bet offer is a combination of betting type and criterion for one or several outcomes with associated odds exists. Each bet offer (also known as "market") has exactly one type. A criterion describes the bet offer, what a player is offered to bet on. All outcomes have common attributes like type, englishLabel, label plus general data like id, odds, status etc.
List View
The List View is a resource which should be used for end-user clients to display events and their major bet offers, allowing various ways of filtering both events and bet offers. This resource should not be used for getting all events or bet offers in the offering. For that use case, the /group resource should be used. By default only events in-play (ongoing) or starting in the near future is included. A fast client should not be bombarded with a lot of events if it will only show a few of them. Which events that are included is highly depending on the term filtering in the URL path-request but also what kind of events are available. Syntax:
.../listView/{sports}/{regions}/{leagues}/{participants}/{attributes}.json
The attributes are used to do a separate filtering on top of the term filtering (filtering by path). They are:
Others
Other feeds offered in the Kindred API set are a mix of things and include:
The Right Kindred API - Racing
When using the Kindred Racing APIs, the approach is more direct as there are a concise set of APIs available to you. The first feed to consider is the Race Meetings.
Meetings
This is the first feed to call to get the list of race meetings. Each meeting contains the basic information; name, race type, conutry code, a list of events, are among them. The information contained with the events list is general too, such as race type, distance, country code information, and it's id. Here is a sample call:
../meetings.json?app_id=xxxx&app_key=xxxx&searchRequest.startDateTime=2019-04-17&searchRequest.endDateTime=2019-04-19
Notice the startDateTime and endDateTime. These are mandatory paramaters with a restriction of three days duration between them, and should adhere to the following format:
yyyy-mm-dd or yyyy-mm-ddThh:mm:ss.000Z
Events
With the ids gained from the meetings call made, you can use these to call individual events using the events feed. This feed returns the racing event which contains a list of competitors, which in turn contains a list of prices. This will be what the average user is interested in. Other information includes, jockey names, trainers, position and weight. Here is a sample call:
../events/201904170900.G.AUS.rockhampton.4.json?app_id=xxxx&app_key=xxxx
Futures
The futures feed provides a list of racing events for longer term bets, and will usually be handled separately from regular events in the client. These are also know as ante-post events. It's a longer term bet where trading is on the outcome of an event, such as the winner of the Grand National. Betting this far in advance can have greater risks, but also enhanced odds. Here is a sample call:
../futures.json?app_id=xxxx&app_key=xxxx
The same event list structure is returned as in the meetings call, and it can simialarly be filtered by raceType, for a more concise results set. These are the raceTypes: