What a Pick6 change feed records: notes from the first day

Change history sounds like a list of line moves. In this API it is more specific: a sequence of differences between stored observations of one market row. Reading its first day of records is a good way to learn what your alerts should and should not assume.

What gets recorded

First captures establish a baseline, and unchanged captures and live-stat ticks do not manufacture offer changes. Empty history is valid until an actual offer change is observed. A history row carries change_id and previous beside the observed row, so a consumer can compare the two values directly without keeping its own copy. One market row holds one target value, so these rows record multiplier and availability changes; a new target appears as a different market row of the same prop.

The first recorded day, measured

A read-only query on November 3, 2026 at 19:24 UTC found 2,204 recorded changes, the earliest captured at 03:01 UTC that day. That is one short window and not a trend. The composition is still instructive.

No change in this window altered target_value on the same market row. A row can change in more than one way, and the sample covers a few hours, so do not read that as a rule. The practical lesson is narrower: an alert that fires only on target_value would have stayed silent through this whole window, while most recorded changes concerned selections. Decide which comparison your product means, and write it explicitly.

Three ways to consume changes

Polling with a saved position

Start with after=0 and advance with the returned pagination.next_after, using offset 0 when advancing after. Save your position only after your own transaction commits. If a run fails halfway through a page, reading that page again and upserting on change_id is safer than skipping work you have not applied.

curl --fail-with-body "https://draftkingsapi.com/api/v1/pick6/history?after=0&limit=25" \
  -H "Authorization: Bearer $DRAFTKINGS_API_KEY"

Starting a stream with a baseline

Read /api/v1/stream/snapshot first and save its snapshot_cursor, then connect to /api/v1/stream with Last-Event-ID or after. Without a cursor, you have to choose start=latest explicitly, or the server returns 428. The stream is not sport-filtered, so apply your snapshot's filter to incoming changes on your side.

A cursor that has been purged returns 410, and the fix is a new snapshot. A cursor ahead of retained changes returns 409, so check that the saved position came from the same deployment you are reading.

What a change does not mean

• Disappearance from a partial category is not settlement.
• A change is a difference between two captures. Moves that revert between captures are invisible.
• Standings multipliers are not decimal odds or probabilities, so a multiplier change is not a price signal.
• The observed time is a capture clock. Source market update time is unknown.