Reading PrizePicks line history without inventing movement

Line history is a sequence of recorded observations. It is not a guarantee that every intermediate update was captured. A collection taken at 12:00 and another at 12:15 can prove the value changed between those observations; neither can prove the exact second of the upstream change. That distinction matters when building alerts, charts, and backtests.

Keep three different times separate

The API records observed_at for collection time and source_updated_at when the provider supplies a parseable upstream timestamp. It also records first_seen_at for the first observation retained by this service. None of these should silently become an opening-line timestamp. If a dataset starts today, it cannot supply yesterday’s opening board.

History begins when this service observes an offer. The history endpoint stores changed snapshots rather than repeating an identical line on every collection. An initial history entry is useful evidence of a starting observation, but a one-point chart does not show movement.

Request history by projection ID

curl "https://prizepicksapi.com/api/v1/projections/PROJECTION_ID/history?limit=100" \
  -H "Authorization: Bearer $PRIZEPICKS_API_KEY"

Replace PROJECTION_ID with an ID returned by the live projections endpoint. History records have their own IDs, the projection ID, observed timestamp, line, selections and status. When meta.next_cursor is present, request the next page using that value. Do not join unrelated offers simply because their display names match.

Understand the four event types

A display-name change, selection change, or event-detail update can produce offer.changed without a numeric line change. For a line-movement alert, explicitly compare previous_line with line. Preserve both values in the alert and include observed_at. Avoid interpreting movement alone as a recommendation or a winning probability.

Consume the change feed without losing your place

curl "https://prizepicksapi.com/api/v1/changes?league=NBA&limit=100" \
  -H "Authorization: Bearer $PRIZEPICKS_API_KEY"

Save the last successfully processed event cursor after committing its effect in your application. On the next poll, pass that cursor as after or cursor, using the same filters. Do not send both parameters. A page with no continuation token can still contain events; save the final event’s cursor before polling again. If processing fails halfway through, re-reading and deduplicating by event ID is safer than advancing beyond unprocessed work.

Absence is not automatically a removal

A provider can return a successful run with an empty, filtered, capped, or partially collected dataset. A platform error can also appear as a diagnostic row. The ingestion pipeline therefore treats completeness as a separate claim from request success. Unverified or partial snapshots do not imply that every missing offer became unavailable.

For trusted complete snapshots, the current pipeline confirms absence across two complete collections before marking an unseen active offer unavailable. A failed or partial collection cannot trigger that inference. Explicit unavailable source states are a separate observation. Keep the collection scope stable when comparing boards: a Points-only snapshot cannot establish that Rebounds offers disappeared.

Build honest charts and backtests

• Label charts with the observation window and timezone, preferably UTC in storage.
• Show gaps when collections are stale instead of drawing an implied uninterrupted feed.
• Keep unknown selection availability and payout values as unknown.
• Separate base lines from promotional offers and separate recorded lines from official results or settlement.
• Record your input data version and observation cutoff so a later snapshot cannot leak into an earlier backtest.