Monitoring Data Changes

This integration scenario explains how to efficiently monitor updates across Golf data using the Daily Change Log feed. Instead of repeatedly polling multiple endpoints, applications can use the change log to detect which data has changed and selectively refresh only the affected resources.

This approach is especially useful for keeping schedules, tournament data, player profiles, and statistics current while conserving API call limits.

This scenario is commonly used to:

• Detect tournament schedule or status changes
• Refresh player profiles and seasonal statistics
• Monitor pairing and tee time updates
• Keep cached data synchronized
• Reduce unnecessary polling of core feeds

Overview

The Daily Change Log acts as a centralized index of data modifications for a given date. It does not return full datasets. Instead, it provides entity IDs and timestamps indicating what has changed.

Your application can then use those IDs to call the appropriate Golf feeds and retrieve updated data only where needed.

A typical workflow looks like this:

Daily Change Log → Identify changed entities → Refresh relevant feeds

Relevant Feeds

The following feeds are commonly used when monitoring Golf data changes:

High-Level Workflow

A typical data monitoring integration follows this loop:

Integration Steps

1. Call the Daily Change Log

Start by calling the Daily Change Log for the date you want to monitor.

The response includes:

• A start_time and end_time window

• Lists of changed entities such as:

  • players
  • participants
  • statistics
  • tournaments (including nested field and round.pairing updates)

• A last_modified timestamp for each entity

The change log only indicates what changed, not what the new values are.

Two entity types sound similar but are distinct. players entries are tour-level person records: an entry there means biographical or identity data changed. participants entries are tournament-scoped: an entry there means a player's relationship to a specific event changed, such as being added to or removed from the field, or picking up a status like CUT or WD.

2. Identify Changed Entity Types

Review which sections are present in the response. Only entity types that have changed during the time window are included. If a section is not present, no changes occurred for that entity type during the requested window.

{
  "start_time": "2023-05-01T04:00:00+00:00",
  "end_time": "2023-05-02T03:59:59+00:00",
  "players": [
    {
      "id": "bb89bd17-d099-4108-ab5b-7c9ebe3068a8",
      "full_name": "Ryan Cole",
      "last_modified": "2023-05-01T19:03:36+00:00"
    }
  ]
}

{
  "participants": [
    {
      "id": "f0ff1391-fc29-41bf-b46a-cd5ef9f63ad9",
      "full_name": "Collin Morikawa",
      "last_modified": "2023-05-01T15:12:11+00:00",
      "season": {
        "id": "ece9907c-6fe3-4944-8cb9-bb1033270259",
        "year": 2023
      }
    }
  ]
}

{
  "statistics": [
    {
      "id": "7da9d857-1f6b-4d76-9396-592d5d9d65eb",
      "full_name": "Seamus Power",
      "last_modified": "2023-05-01T14:10:14+00:00",
      "season": {
        "id": "ece9907c-6fe3-4944-8cb9-bb1033270259",
        "year": 2023
      }
    }
  ]
}

{
  "tournaments": [
    {
      "id": "0262529f-2ea5-4f77-b1ed-42c4d81e09ea",
      "name": "PGA Championship",
      "currency": "USD",
      "event_type": "stroke",
      "last_modified": "2023-05-01T15:11:54+00:00",
      "course_timezone": "America/New_York",
      "season": {
        "id": "ece9907c-6fe3-4944-8cb9-bb1033270259",
        "year": 2023
      },
      "field": [
        {
          "id": "4dc6e9c7-dd5b-4cf2-a7fe-b9c94c7a9110",
          "full_name": "Jason Dufner",
          "last_modified": "2023-05-01T15:12:24+00:00"
        }
      ]
    }
  ]
}

For example:

• A tournament appearing under tournaments may indicate:

  • A status update (scheduled → inprogress → closed)
  • A schedule or date change
  • Updates to the field, pairings, or tee times

• Entries under players often reflect:

  • Biographical corrections
  • Name or profile adjustments
  • New player records

• Entries under participants typically reflect:

  • A player being added to or removed from a tournament field
  • Status changes for a player in a tournament (CUT, WD, etc.)

• Statistics updates typically occur:

  • After tournaments complete
  • During weekly season stat validation (Monday, about 17:00 UTC)

Your application should treat each section independently and only react to the data types it cares about.

3. Refresh Affected Feeds

Use the returned IDs to selectively call the appropriate Golf feeds.

Examples:

• Tournament ID → refresh Tournament Schedule, Tournament Summary, Tournament Leaderboard
• Pairing or round changes (nested under tournament) → refresh Tee Times Per Round
• Player ID → refresh Player Profile
• Statistics changes → refresh Player Statistics

This targeted approach avoids unnecessary full-season refreshes.

4. Handle Timing and Frequency

The Daily Change Log is designed to be polled at regular intervals based on your platform's freshness requirements.

Best practice is to:

• Poll every 4 hours or so, matching the Update Frequencies guidance; once daily can suffice if you only need day-level sync
• Increase frequency during active tournament weeks
• Use the last_modified timestamps to determine recency
• Recover from downtime by requesting the missed dates directly; the log is queryable for any past date in the covered seasons
• Combine with update frequency guidance from individual feeds
• For more details, see the Update Frequencies page

Common Use Cases

Typical builds on this workflow include:

• Keeping cached schedules in sync
• Updating tournament results immediately after play concludes
• Detecting late tee time or pairing changes
• Refreshing player updates and field additions
• Powering backend data ingestion pipelines

Best Practices

• Use the Daily Change Log as a trigger, not a data source
• Only refresh feeds related to changed entities
• Do not poll tournament or statistics feeds unnecessarily
• Expect statistics updates after tournaments complete and during weekly validation
• Combine change detection with the per-feed update frequencies
• Treat downstream feeds as the source of truth for full datasets