Monitoring Data Changes

The Daily Change Log lists the IDs and last_modified timestamps of everything modified on a given league day: schedule adjustments, game results and statistics, player updates (such as name or number changes), team modifications, and standings, plus any games removed from coverage. A request for one date returns that day's entries grouped by entity type, and the IDs point at the feeds to refetch. It turns "re-pull everything nightly" into "refetch only what changed", which keeps your call volume low across a league of this size, and it is the recovery tool after downtime.

This scenario is commonly used to:

Keep a local store of players, results, schedules, standings, and rankings synchronized with targeted refetches
Catch post-game corrections, including the defensive statistics that settle in the week after a game
Detect roster, transfer, eligibility, and profile edits without polling every profile
Recover cleanly after an outage by walking the missed days

Relevant Feeds

Feed	Scope	Use
Daily Change Log	`{year}/{month}/{day}`	What changed that league day
Player Profile	`{player_id}`	The refetch target for `players` entries
Game Statistics	`{game_id}`	The refetch target for `results` entries

High-Level Workflow

Daily Reconciliation LoopOne pull per league day, targeted refetches

Pull dailyDaily Change Log→playersscheduleresultssections appear only when that day changed them

RefetchPlayer ProfileGame StatisticsPostgame Standingsonly entities the log lists

Prunedeleted_games→local storedrop schedule rows the Season Schedule lists as deleted

Past dates stay queryable: on recovery from downtime, walk the missed league days in order.

Integration Steps

1. Pull the league day

The date trio addresses one league-defined day, midnight to midnight US Eastern time, expressed in UTC in the response's start_time and end_time: 04:00:00Z to 03:59:59Z while daylight saving time is in effect (as below) and 05:00:00Z to 04:59:59Z in standard time. Entries populate live as changes are made, so a request during the day returns what has changed so far.

LEAGUE DAYone change-log day on the UTC clock, from the response below

UTC clock

Sep 2

league day 2026-09-02 · 04:00:00Z to 03:59:59Z

Sep 3

US Eastern (EDT, UTC-4)

Sep 1

Wednesday, September 2 · midnight to midnight

Sep 3

start_time 2026-09-02T04:00:00Zend_time 2026-09-03T03:59:59Z

One league day is midnight to midnight US Eastern. While daylight saving time is in effect it spans 04:00:00Z to 03:59:59Z; in standard time the boundary moves an hour later, 05:00:00Z to 04:59:59Z. A change entered at 11 p.m. Eastern belongs to that Eastern date, not to the next UTC date.

GET https://api.sportradar.com/ncaafb/trial/v7/en/league/2026/09/02/changes.json
x-api-key: YOUR_API_KEY

{
  "league": {
    "id": "26c1246a-2fc3-4b7e-8999-1685d3ab4676",
    "name": "NCAA Football",
    "alias": "NCAAFB"
  },
  "start_time": "2026-09-02T04:00:00Z",
  "end_time": "2026-09-03T03:59:59Z",
  "players": [
    {
      "id": "001c76c0-4054-11ee-b34f-1f4d18abd94a",
      "full_name": "Jack Ramsay",
      "last_modified": "2026-09-02T23:52:37+00:00"
    },
    {
      "id": "00292050-8610-11f1-b79b-430a92b58a59",
      "full_name": "Adrian Ortiz",
      "last_modified": "2026-09-02T23:48:00+00:00"
    }
  ],
  "schedule": [
    {
      "id": "0cd1ced4-3c8a-4c1a-a9a1-1f91065b341e",
      "season_id": "fc822580-0db7-11f1-baa3-21a52b3e3c8d",
      "last_modified": "2026-09-02T13:53:40+00:00",
      "sr_id": "sr:match:70924674"
    },
    {
      "id": "cbdd459a-6c65-48cc-940f-3e9c47fd4361",
      "season_id": "fc822580-0db7-11f1-baa3-21a52b3e3c8d",
      "last_modified": "2026-09-02T13:53:47+00:00",
      "sr_id": "sr:match:70924570"
    }
  ],
  "results": [
    {
      "id": "36dfce11-c70c-430f-868a-3c27e990bf13",
      "season_id": "fc822580-0db7-11f1-baa3-21a52b3e3c8d",
      "last_modified": "2026-09-02T17:30:09+00:00",
      "sr_id": "sr:match:70972356"
    },
    {
      "id": "755b95e6-b06a-4b4d-8344-bdf338fb9455",
      "season_id": "fc822580-0db7-11f1-baa3-21a52b3e3c8d",
      "last_modified": "2026-09-02T13:56:25+00:00",
      "sr_id": "sr:match:70994282"
    }
  ]
}

<?xml version="1.0" ?>
<!-- Generation started @ 2026-09-03 08:07:32 +0000 -->
<league xmlns="http://feed.elasticstats.com/schema/football/changelog-v7.0.xsd" id="26c1246a-2fc3-4b7e-8999-1685d3ab4676" name="NCAA Football" alias="NCAAFB">
  <changelog start_time="2026-09-02T04:00:00Z" end_time="2026-09-03T03:59:59Z">
    <profiles>
      <players>
        <player id="001c76c0-4054-11ee-b34f-1f4d18abd94a" full_name="Jack Ramsay" last_modified="2026-09-02T23:52:37+00:00"/>
        <player id="00292050-8610-11f1-b79b-430a92b58a59" full_name="Adrian Ortiz" last_modified="2026-09-02T23:48:00+00:00"/>
        <!-- ... omitted for brevity -->
      </players>
    </profiles>
    <games>
      <schedule>
        <game id="0cd1ced4-3c8a-4c1a-a9a1-1f91065b341e" season_id="fc822580-0db7-11f1-baa3-21a52b3e3c8d" last_modified="2026-09-02T13:53:40+00:00" sr_id="sr:match:70924674"/>
        <game id="cbdd459a-6c65-48cc-940f-3e9c47fd4361" season_id="fc822580-0db7-11f1-baa3-21a52b3e3c8d" last_modified="2026-09-02T13:53:47+00:00" sr_id="sr:match:70924570"/>
      </schedule>
      <results>
        <game id="36dfce11-c70c-430f-868a-3c27e990bf13" season_id="fc822580-0db7-11f1-baa3-21a52b3e3c8d" last_modified="2026-09-02T17:30:09+00:00" sr_id="sr:match:70972356"/>
        <game id="755b95e6-b06a-4b4d-8344-bdf338fb9455" season_id="fc822580-0db7-11f1-baa3-21a52b3e3c8d" last_modified="2026-09-02T13:56:25+00:00" sr_id="sr:match:70994282"/>
        <!-- ... omitted for brevity -->
      </results>
    </games>
  </changelog>
</league>
<!-- Generation ended @ 2026-09-03 08:07:32 +0000 -->

The response is reduced here to two entries per section. Player entries carry the GUID, full_name, and last_modified; game entries carry the GUID, the season_id that tells you which season's feeds to refetch, last_modified, and the sr_id shared with other Sportradar products. The sections:

players: players whose profile data changed, such as a name or number edit, a roster move, an eligibility change, or a status change
schedule: games whose scheduling data changed
results: games whose result or statistical data changed; an ID here means some data associated with the game was modified, which is not necessarily the final score
Team and standings changes are covered the same way and appear as their own sections when they occur

In XML, the profile entries sit under profiles and the game entries under games. Sections appear only when that day changed them, so parse by the sections present rather than expecting a fixed set. The full response for the day above, an early-season Wednesday, lists 555 players, 2 games under schedule, and 8 games under results.

2. Refetch what the log lists

Each section maps to a refetch target. Use the listed IDs, and skip entries whose last_modified you already hold.

Section	Refetch
`players`	Player Profile per listed ID, plus the owning Team Roster when the change is a roster move
`schedule`	The affected week's Weekly Schedule, or the Season Schedule on bulk days
`results`	Game Statistics, Game Play-by-Play, Game Boxscore, and Game Roster per listed game ID, depending on what you store
team entries	Team Roster per listed team ID
standings	Postgame Standings once per affected season, and the Rankings (Current Week) or Rankings (By Week) feeds when a change could move the polls

The same four moves apply to every scenario: identify the change types from the sections present (each entry lists a game, player, or team ID); use the IDs to decide the refetch (a game ID under results signals a change in game-related data, while a player or team ID signals a change to that entity, such as a profile update or a roster edit); pull the detailed data from the relevant feed; then compare the newly retrieved data against what you stored to verify the change and update your records.

Which scenario watches which section, and what it refetches:

Scenario	Watch	Refetch	Worth noting
Tracking Live Games	`results`	Game Play-by-Play for new plays added or corrections to existing play records; Game Statistics for player statistics and team performance metrics after post-game corrections; Game Boxscore for adjustments to game summary data, including final scores or statistical errors being rectified	The game feeds move to a longer cache once a game is `closed`, so the change log is how you capture data changes after a game has ended. Tackle detail (tackles, assists, passes defended, and quarterback hits) is unofficial, can be incomplete at `closed`, and is completed during the following week; the NCAAFB FAQ lists which statistics are considered unofficial
Tracking Standings and Rankings	`results`	Postgame Standings, then the rankings feeds	Standings and rankings changes after games conclude are rare (a corrected game statistic, a review of play outcomes, a late-reported result), and a `results` entry means game-related details changed, not necessarily the final score
Retrieving Rosters and Players	`players`, team entries, `results`	Team Roster for player transfers, eligibility changes, and updates to the active roster; Game Roster for post-game corrections to player participation (a game ID under `results`)	Roster adjustments and corrections to player statistics surface here; pair with Daily Transactions and the Transfer Portal for the movement detail
Retrieving Seasonal Statistics	`results`	Game Statistics first (its values feed seasonal totals), then Seasonal Statistics for the team ID taken from that game, and Player Profile for the players involved	A corrected game statistic changes seasonal totals; League Leaders, Player Profile, and Seasonal Statistics update within minutes of a game moving to `closed`, and later corrections reach them through the change log
Pulling Schedules	`schedule`, `deleted_games`	Weekly Schedule or Season Schedule	Reconcile `deleted_games` on every pull (step 3)
Retrieving Historical Data	any past date	Seasonal Statistics for the season listed	Past dates stay queryable, so statistical updates to past seasons are caught the same way

A players entry refetches one profile. The profile carries the player's current status and eligibility plus the season-by-season team history, so a transfer shows up as a new team on the latest season:

GET https://api.sportradar.com/ncaafb/trial/v7/en/players/000d8f6e-5a71-4214-9bd9-b33f43502527/profile.json
x-api-key: YOUR_API_KEY

{
    "id": "000d8f6e-5a71-4214-9bd9-b33f43502527",
    "name": "Dre Washington",
    "last_name": "Washington",
    "first_name": "Dre",
    "abbr_name": "D.Washington",
    "weight": 216.0,
    "height": 69,
    "position": "RB",
    "birth_place": "Hemphill, TX, USA",
    "status": "NWT",
    "eligibility": "SR",
    "seasons": [
        {
            "id": "d1132b13-2c29-4e6d-9011-b627c7fd9a17",
            "year": 2021,
            "type": "REG",
            "name": "REG",
            "teams": [
                {
                    "id": "2dec939a-f303-43ac-964d-37e81f75e286",
                    "name": "Ragin' Cajuns",
                    "market": "Louisiana",
                    "alias": "ULL"
                }
            ]
        }
    ]
}

<?xml version="1.0" ?>
<!-- Generation started @ 2026-08-23 15:50:38 +0000 -->
<player xmlns="http://feed.elasticstats.com/schema/football/profile-v7.0.xsd" id="000d8f6e-5a71-4214-9bd9-b33f43502527" name="Dre Washington" last_name="Washington" first_name="Dre" abbr_name="D.Washington" weight="216.0" height="69" position="RB" birth_place="Hemphill, TX, USA" status="NWT" eligibility="SR">
  <season id="d1132b13-2c29-4e6d-9011-b627c7fd9a17" year="2021" type="REG" name="REG">
    <team id="2dec939a-f303-43ac-964d-37e81f75e286" name="Ragin' Cajuns" market="Louisiana" alias="ULL">
      <!-- ... omitted for brevity -->
    </team>
  </season>
  <!-- ... omitted for brevity -->
</player>
<!-- Generation ended @ 2026-08-23 15:50:38 +0000 -->

A results entry refetches the game's statistics. The team blocks at the top of the response hold the team IDs you pass to Seasonal Statistics; the CFP National Championship, reduced here to the game header and the team identifiers:

GET https://api.sportradar.com/ncaafb/trial/v7/en/games/ac60aab5-2638-45de-87f0-037e3f199282/statistics.json
x-api-key: YOUR_API_KEY

{
  "id": "ac60aab5-2638-45de-87f0-037e3f199282",
  "status": "closed",
  "title": "CFP National Championship",
  "statistics": {
    "home": {
      "id": "fa0eb091-8e35-49c7-b00f-269794a99a61",
      "name": "Hoosiers",
      "market": "Indiana",
      "alias": "IND"
    },
    "away": {
      "id": "2f475a40-df87-43a7-b8a9-c36a43edff21",
      "name": "Hurricanes",
      "market": "Miami (FL)",
      "alias": "MIA"
    }
  }
}

3. Prune deletions

When a game is removed from coverage (for example, a duplicate or an erroneously created game), it is not silently dropped from the API. Removed games surface in three places:

The change log carries a deleted_games node beside its other sections on days when a deletion occurs, listing each removed game's ID
Season Schedule and Weekly Schedule responses carry the same reconciliation list in a top-level deleted_games array
The game itself keeps serving from the game-level feeds (Boxscore, Play-by-Play, Roster, Statistics) with a deleted: true flag

To keep your system consistent, store the deleted game IDs so downstream processing (statistics, standings, displays) suppresses them rather than treating a previously ingested game as still active, reconcile the deleted_games array against your stored games on each schedule pull, and include the affected weeks in your reconciliation pass. Pulling Schedules covers the schedule feeds themselves.

4. Recover from downtime

Past dates stay queryable, so an outage is repaired by walking the missed league days in order and applying each day's refetches before moving on. The cache follows the age of the date requested (15 minutes for the current day, 1 hour for the current month, 4 hours for the current year, 12 hours for past years), so a backfill of older days can run at any pace while the current day stays on its normal cadence. The same walk catches statistical updates to past seasons for a historical store.

Best Practices

Pull every 10 minutes or less, depending on your use case, and once more after the league day closes so the day's full entry set is applied
Keep polling through the week after each game day: tackle detail settles during the following week and those games reappear under results
Pair the change log with Daily Transactions and the Transfer Portal when a players section appears: the transaction records carry the movement detail
Store last_modified per entity and make refetches idempotent
Treat a results entry as "something about this game changed": refetch the game feeds and compare before assuming the score moved
The change log is a pointer feed: it tells you what to refetch, not what changed inside the entity
Cache and data-update timing for the change log and every refetch target is on Update Frequencies