GET Latest Updated Livescores

Returns you all livescores that have received updates within 10 seconds.

Base URL

https://api.sportmonks.com/v3/football/livescores/latest

Example Response

Field Description

Query Parameters

Name	Required?	Description
api_token	YES Another option is to provide the API token in the header.	Your unique API token. Ex. ?api_token=YOUR_TOKEN
include	NO	Enrich the API response with more data by using includes. Ex. &include=participants;events
select	NO	Select specific fields on the base entity. Read how to select fields in our tutorial.
sortBy	NO	Order by specific fields on the base entity. For more information check out this page.
filters	NO	Filter the API response on multiple related entities. There are static filters and dynamic filters.​ Please find the possibilities in the Static and Dynamic Filter tab.
locale	NO	Translate name fields of the API Response in your selected language. Find more information and which languages are available on our translations page.

Static Filters

Dynamic Filters

Definition of "Latest Updated"

The Latest Updated endpoint returns all fixtures whose livescore data has changed within the last 10 seconds. Specifically, it tracks changes to these eight fields: state_id, venue_id, name, starting_at, starting_at_timestamp, result_info, leg, and length. The update window is fixed at 10 seconds and cannot be altered.

Changes to each core field mean the following:

• State_id – the match phase progressed (for example, from 1 to 2 at kick-off or from 2 to 3 at half-time)

• Venue_id – the assigned venue was updated (for example, moved from stadium A to stadium B)

• Name – the fixture name text was modified (for example, team abbreviations or formatting changed)

• Starting_at – the kick-off time string was rescheduled (for example, “2024-08-04 15:30:00” to “2024-08-04 16:00:00”)

• Starting_at_timestamp – the UNIX timestamp for kick-off was rescheduled (for example, 1722785400 to 1722787200)

• Result_info – the score summary text was updated (for example, “0-0” to “1-0”)

• Leg – the leg designation changed (for example, “1/2” to “2/2”)

• Length – the fixture duration changed (for example, 90 to 120 when extra time is added)

Note: Only these eight fields are monitored. Changes in other data (e.g. events, lineups, odds, statistics) do not count toward triggering this endpoint. The 10-second window is fixed and non-configurable.

Update behaviour & edge cases

• On each request, the system checks the previous 10 seconds to see which fixtures had one or more of those eight fields changed.

• If no fixtures experienced changes during that interval, the response is 200 OK with "data": [].

• Because of the short window, updates usually arrive in small batches.

• If multiple changes occur to the same fixture within the 10-second span, you may only see the final post-change state, not every intermediate step.

• Pay attention to clock skew (between your system and the API’s time) and network jitter, as they may cause missing updates or duplicate detections.

Polling strategy & best practices

• Recommended polling interval: 5–8 seconds, as long as rate limits permit.

• If you detect many consecutive empty responses, consider backing off (e.g. increasing the interval) to reduce unnecessary calls.

• Always dedupe via your cache: ignore fixtures whose tracked fields haven’t changed.

• Use exponential backoff or pauses when encountering errors, and safely resume polling without flooding.

Caching & diff logic

Your local cache should store for each fixture the current values of the eight tracked fields.

Polling workflow:

1. Call GET /v3/football/livescores/latest?[params]

2. For each fixture in the data array:

   • Compare each of the eight fields with your cached version

   • If no differences → skip

   • If any difference → process this as an update and overwrite your cache

3. If you need more context (events, lineups, odds), fetch via other endpoints (e.g. Fixture by ID, Inplay Livescores)

4. Separately, maintain cached metadata (teams, leagues, venues) since they rarely change.

Let polling interval = 6 seconds

T = now  
 → GET latest → returns fixtures A, B  
 → Compare with cache → apply updates for changed ones  
 → Update cache  

T + 6s  
 → GET latest → returns fixtures B, C  
 → Process B (if changed), process C  
 → Update cache  

T + 12s  
 → GET latest → returns []  
 → No changes, skip processing  
 → Optional: if many empties, slow poll rate  

Filters

More information on how to use filters can be found in our tutorials on how to filter. If you want more information on which filters to use, you can check out the following endpoint:

https://api.sportmonks.com/v3/my/filters/entity?api_token=YOUR_TOKEN

Pagination

NO

Include depth

You can use a total of 3 nested includes on this endpoint

Include options

sport round stage group aggregate league seasoncoaches tvStations venue state weatherReport lineups events timeline comments trends statistics periods participants oddspremiumOdds inplayOdds prematchNews metadata sidelinedpredictions referees formations ballCoordinates scoresxGFixture expectedLineups

Related Entities:

Get an overview and explanation of all the fields returned in the API response. The related entities for the livescores endpoints are:

• Fixture

Postman

We also offer detailed postman documentation with examples and a complete up-to-date version of all our endpoints. Below is a button that lets your fork the collection or import it.

Code Example

Ruby

require "uri"
require "net/http"

url = URI("https://api.sportmonks.com/v3/football/livescores/latest?api_token=YOUR_TOKEN")

https = Net::HTTP.new(url.host, url.port)
https.use_ssl = true

request = Net::HTTP::Get.new(url)

response = https.request(request)
puts response.read_body

Python

PHP

Java

Node.js

Go