🔧Best Practices

Our API provides well-structured responses with strictly typed entities, such as statistics and lineups. This page provides best practices for using our data effectively in sports applications.

Initial data load

Most of our endpoints support pagination, which means that you need to make multiple requests to retrieve all data. To make this process more efficient, we have added several options for fetching data and keeping it up to date.

You can use the filters=populate query parameter on any endpoint to enable or disable certain features. When enabled, it disables all possible includes to avoid large responses and allows pagination with a page size of 1000 records. This significantly reduces the number of requests required to retrieve all data.

After you have retrieved all data, you can use the idAfter filter (ex. filters=idAfter:50000) to keep your database in sync. This filter allows you to specify an ID, and it will only fetch records with IDs greater than the specified ID on the requested entity. You can quickly load and maintain your database using the idAfter filter combined with the populate filter.

Reducing includes and response data

Our API uses Types extensively, often available as optional includes on most endpoints. To reduce the number of includes in your requests, we recommend storing Types in your database or cache. This way, you can determine an entity type without using an include all the time. Here's a complete list of the entities we recommend caching:

• States

• Types

• Continents

• Countries

• Regions

• Cities

Caching these entities can reduce the number of includes in your requests by up to half, saving bandwidth and improving response times.

Working with scores

When you're working with sports scores, it's important to have a way to retrieve all the scores for a specific fixture.

That's why we've included a feature that allows you to do just that. Each game has a set of scores that come with a description and type to help you understand when they were scored, for example "1ST_HALF" and "2ND_HALF". To make it even easier, we've also added a "CURRENT" indicator. This is the best option to use if you want to display the latest scores for a game, including any extra time that may have been played.

You can retrieve scores for a fixture by using the &include=scores parameter.

{
    scores: [
        {
            "id": 11957222,
            "fixture_id": 18543696,
            "type_id": 1525,
            "participant_id": 240,
            "score": {
                "goals": 0,
                "participant": "away"
            },
            "description": "CURRENT"
        },
        ...more score entries
    ]
}

CORS (Cross-Origin Resource Sharing)

If you are developing your sports application in your browser, you might be running into something similar to the following error:

"Request from origin https://your_domain.com has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource"

This is because you are directly integrating our API into the front-end of your application (most likely a browser). Directly integrating an API into the frontend of a web application can be risky as it can expose sensitive information, such as your Sportmonks API token, to potential security breaches.

To avoid this, it is best practice to use a middleware, such as a backend or proxy server, to handle all communication between the frontend and the API. This middleware acts as an intermediary, making sure your API tokens are stored securely and not exposed to users. Using middleware makes it much harder for malicious actors to access sensitive information, keeping your application more secure overall.