---
id: update-guidelines
title: Sport Line API — Data Update Guidelines
description: Recommendations for request frequency and updates to menus, matches, odds, and Live data.
version: v1
language: en
---

# Sport Line API — Data Update Guidelines

## Why Data Must Be Updated

Sport Line API uses REST API. Each request returns a current snapshot of the data at the
time of the request.

To receive score, period, statistics, and odds changes, the client application must
repeat its requests at the recommended intervals.

WebSocket support is under development and is not currently used in production
integrations.

## Recommended Intervals

An interval of “5 seconds minimum” means that a request must not be sent more often than
once every 5 seconds.

| Data or methods | Live | Prematch (`line`) |
|---|---:|---:|
| Full menu: `menu` | 20 seconds minimum | 60 seconds minimum |
| Step-by-step navigation: `sports`, `countries`, `tournaments` | 60 seconds minimum | 120 seconds minimum |
| Match list: `events` | 7 seconds minimum | 30 seconds minimum |
| Specific match: `event` | 5 seconds minimum | 30 seconds minimum |
| Top matches: `topmatches` | 30 seconds minimum | 120 seconds minimum |
| Top matches for a selected sport: `toplist` | Not used | 120 seconds minimum |

The method for retrieving Prematch events by time period is not yet ready for client
integrations. Do not use it until its contract has been fixed and approved.

If the SportAPI manager provides different intervals for your connection, use the
values provided by the manager.

## Update the Menu and Match List at Different Intervals

The menu changes less frequently than scores and odds, so you should not request `menu`
every 5 seconds.

Use `events` to update the match list. Use `event` to update the detailed data of one
match currently open in the interface.

Do not request `event` for every match returned by `events` unless those details are
shown to the user. Doing so creates a large number of unnecessary requests.

## Do Not Request the API Every Second to Update the Timer

Do not request Sport Line API every second merely to update the match timer on the
screen.

1. Retrieve the `timer` value from the API.
2. Update the displayed timer locally in the interface.
3. Synchronize the timer with the new API value during the next scheduled request.

When updating the timer locally, account for pauses, breaks, and timer stoppages, which
may differ between sports.

## Match Lifecycle

A match may move from Prematch to Live. When this happens, the Live match receives a new
`game_id` that does not match the `game_id` of the Prematch match.

Do not link Prematch and Live matches by `game_id`. Sport Line API does not return a
separate status that can reliably indicate that a Prematch match has started and moved
to Live.

When a match is no longer available in the current line, an `event` request using its
previous `game_id` may return:

```json
{
  "status": 1,
  "page": "/v1/event",
  "body": {
    "message": "Game id finished"
  }
}
```

This message does not explain the reason. The match may have moved to Live under a new
`game_id`, been cancelled, or disappeared from the line for another reason. The API
does not provide separate statuses for these cases.

The application must:

1. Update Prematch and Live data separately.
2. Not link Prematch and Live matches by `game_id`.
3. Retrieve current Live matches from the `events` method with the `live` type.
4. Stop requesting `event` for an ID after receiving `Game id finished`.
5. Not use `Game id finished` to determine whether a match started, ended, or was
   cancelled.

## Retry Recommendation for Failed Requests

This section provides general guidance for the client application. It is not a Sport
Line API requirement or rule.

After a failed request, wait before retrying it.

For a temporary network or server error, you can gradually increase the delay:

```text
5 seconds → 10 seconds → 20 seconds → 40 seconds
```

After a successful response, return to the normal interval.

In general, do not automatically retry errors that cannot be resolved without changing
the request:

- an invalid or expired API key;
- an unavailable language;
- a sport that is not included in the subscription;
- invalid URL parameters.

See [Error Handling](error-handling.md) for more details.

## Prevent Overlapping Requests

If the previous request is still in progress, do not start another request for the same
data.

A safe update cycle looks like this:

```text
send request
      ↓
wait for a response or error
      ↓
process the data and update the interface
      ↓
wait for the required interval
      ↓
send the next request
```

This approach prevents concurrent requests from accumulating when the API or network is
temporarily responding more slowly than usual.

## Quick Checklist

1. Follow the recommended interval for each method.
2. Do not request the menu as frequently as the match list.
3. Do not request a detailed `event` for every match.
4. Update Prematch and Live data separately.
5. Do not start a new request until the previous request has completed.
6. For temporary errors, gradually increasing the retry delay is recommended.
7. Stop frequently updating matches that are no longer available.

Next: [`menu` Method](../api-reference/menu.md).
