Monitoring Data Changes

The Daily Change Log lists the IDs and timestamps of entities modified on a given league day (teams, players, game statistics, schedules, and standings) plus any games removed from the schedule. It turns "re-pull everything nightly" into "refetch only what changed", and it is the recovery tool after downtime.

This scenario is commonly used to:

Keep a local store synchronized with targeted refetches
Detect roster and profile edits without polling every profile
Recover cleanly after an outage by walking missed days

Relevant Feeds

Feed	Scope	Use
Daily Change Log	`{year}/{month}/{day}`	What changed that league day
Daily Transactions	`{year}/{month}/{day}`	The player-movement detail behind roster changes
Weekly Schedule	season + week	The `deleted_games` reconciliation list

High-Level Workflow

Daily Reconciliation LoopOne pull per league day, targeted refetches

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

RefetchPlayer ProfileGame StatisticsPostgame Standingsonly entities the log lists

Prunedeleted_games→local storedrop schedule rows the Weekly 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 the league-defined day, running 04:00:00Z to 03:59:59Z. A day with activity returns sections for the entity types that changed, each entry carrying the GUID and a last_modified timestamp; an in-season day with a played game lists changed players and the game under results:

{
  "league": {
    "id": "d441365f-cfab-49d6-9976-6c95d91fdef7",
    "name": "United Football League",
    "alias": "UFL"
  },
  "start_time": "2026-05-15T04:00:00Z",
  "end_time": "2026-05-16T03:59:59Z",
  "players": [
    {
      "id": "49647f40-50bd-11f1-812a-1141028412f7",
      "full_name": "Jonah Dalmas",
      "last_modified": "2026-05-16T00:25:32+00:00"
    },
    {
      "id": "bf0c7c00-d08c-11ef-951f-e1dd62b8c041",
      "full_name": "Brian Dooley",
      "last_modified": "2026-05-16T00:14:10+00:00"
    }
  ],
  "results": [
    {
      "id": "70b15b0c-cc80-4f80-a899-6862a0b62d53",
      "season_id": "4ee5ece0-6f0b-11f0-b1e6-2dad3ff60df1",
      "last_modified": "2026-05-16T03:15:38+00:00",
      "sr_id": "sr:match:68165620"
    }
  ]
}

Sections appear only when that day changed them. A quiet day returns just the envelope:

{
  "league": {
    "id": "d441365f-cfab-49d6-9976-6c95d91fdef7",
    "name": "United Football League",
    "alias": "UFL"
  },
  "start_time": "2026-07-23T04:00:00Z",
  "end_time": "2026-07-24T03:59:59Z"
}

2. Refetch what the log lists

Map each section to its refetch: players to Player Profile (and the owning Team Roster), results to Game Statistics or Boxscore, schedule entries to the affected week's Weekly Schedule, and standings entries to Postgame Standings. Skip entries whose last_modified you already hold.

3. Prune deletions

Removed games surface in three places. On a day that removed games, the change log response carries a deleted_games section beside the changelog node listing each removed game's ID. The Weekly Schedule and Season Schedule carry the same reconciliation list in their deleted_games arrays. And a game feed pulled for a removed game flags it with deleted: true. Drop the listed IDs from your store, and include the affected weeks in your reconciliation pass.

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.

Best Practices

Pull once per league day shortly after 04:00:00Z, and again intraday during active periods such as game days and roster deadlines
Pair the change log with Daily Transactions when a players section appears: the transaction records carry the movement detail
Store last_modified per entity and make refetches idempotent
The change log is a pointer feed: it tells you what to refetch, not what changed inside the entity