Fixtures API

Fixtures API

A list of all the matches including matches played in the past, present and the ones to be played in the future. Access match schedules, venues, participating teams, organizing associations, and match formats.

Request structure

Here is what you would require to make your first successful HTTP REST Fixtures API call.

Sample Request

TERMINAL
pip install requests
pip install requests
icon copy
get_fixtures.py
import requests project_key = 'YOUR_PROJ_KEY' token = 'YOUR_ACCESS_TOKEN' # For MG100 url = "https://api.sports.roanuz.com/v5/cricket/{}/fixtures/".format(project_key) headers = { 'rs-token': token } response = requests.get(url, headers=headers) print(response.json()) # For MG101 import datetime month = datetime.datetime.now().strftime('%Y-%m') url = "https://api.sports.roanuz.com/v5/cricket/{}/fixtures/mg/MG101/date/{}/page/{}/"".format(project_key, month, 1) headers = { 'rs-token': token } response = requests.get(url, headers=headers) print(response.json())
import requests

project_key = 'YOUR_PROJ_KEY'
token = 'YOUR_ACCESS_TOKEN'

# For MG100
url = "https://api.sports.roanuz.com/v5/cricket/{}/fixtures/".format(project_key)
headers = {
    'rs-token': token
}
response = requests.get(url, headers=headers)

print(response.json())

# For MG101
import datetime
month = datetime.datetime.now().strftime('%Y-%m')
url = "https://api.sports.roanuz.com/v5/cricket/{}/fixtures/mg/MG101/date/{}/page/{}/"".format(project_key, month, 1)
headers = {
    'rs-token': token
}
response = requests.get(url, headers=headers)

print(response.json())
icon copy

Scenarios

We recommend you to go through the following scenarios and keep them in mind while developing your application. A sound knowledge of these scenarios should help you in maintaining the quality of your app.

HTTP Status

Possible status codes you may receive in response to your requests.

Cache

A cache object accompanies every API response. It comes with a set of recommended values to help you properly cache the data and handle the cache internally.

When you try to cache the responses on say MemCached, Redis or any other cache server, you will usually require a Key and an expire time.

cache.key

Our recommendations on what Key or ID you should use while you cache a response of this API.

cache.expires

Our recommendations on how long you can cache a particular response.

An interesting thing to note here is that the recommended expire time is not going to be the same under all situations. Our intelligent caching mechanism dynamically decides the best expire time analysing various parameters.

The cache object also provides you with a max_age and the ETag values, which lets you implement the ETag HTTP caching mechanism. To implement HTTP Caching with this API, refer here.

cache.max_age

Our recommended period of time up to which you can consider the data to be fresh. It gives you a heads up on when you should be checking for updates in the data.

cache.etag

Etag is an identifier for a specific version of a response. To know more, refer here.

The time period specified in max_age will be lesser than that in the expires object. To sum it up, the cache.expires object tells you how long you can cache the data while the cache.max_age object tells you when you should check for updates.

Response Schema

The schema as per which the data is sent by the Fixtures API is explained below. We constantly work on improving our API system, and in some cases, safely introduce new attributes to provide interesting and useful features. To give you a heads up regarding such updates, every successful API response will contain a schema object. It gives the information about the current minor version and major version of the API.