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.

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.

Retrieve the timer value from the API.
Update the displayed timer locally in the interface.
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:

{
  "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:

Update Prematch and Live data separately.
Not link Prematch and Live matches by game_id.
Retrieve current Live matches from the events method with the live type.
Stop requesting event for an ID after receiving Game id finished.
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:

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 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:

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

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

Next: menu Method.