An NBA player props API you can inspect.

Start from the coverage that actually exists

The examples above come from the service’s stored NBA projections and are limited to six records. The coverage summary reports the observed stat names and collection health. Neither a product description nor a fictional demo establishes that every NBA player, market, or game is present. Check the current coverage before deciding which features your application can support.

A projection includes a stable offer ID, player information, league, event context, market name and period, provider base line, separate More/Less selections, and observation timestamps. Some fields can be unknown. Keep those null values in your client and explain them in your interface instead of displaying a zero or an inferred payout.

Query a league and a specific market

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

League filtering narrows the stored collection to NBA. The stat filter matches the actual market name case-insensitively. Points, Rebounds, and Assists are different markets; combo markets such as Points (Combo) remain separate names. A combo offer can involve multiple players or teams, so do not assume every display name identifies one athlete.

Use search when you want to match a player or team string, and use exact projection IDs when storing a particular offer. A player can have multiple offers with different periods or variants. If your UI groups records under a player, preserve those market distinctions so selecting one row cannot accidentally overwrite another.

Paginate before counting the board

An API response is one page. Follow meta.next_cursor with the same filters until no continuation remains. The default limit is 50 and the maximum is 200. Counting only the first page can make a larger collection look incomplete for the wrong reason. Even after all pages are read, source_status may still say partial because complete API pagination does not establish complete upstream coverage.

The six examples on this page are intentionally a fixed public sample, not a page-size control for the authenticated API. Create a key to make filtered authenticated requests, or use the separate fictional demo to build your parser without live data. Do not mix demo and captured records in the same table without an explicit mode label.

Choose state, history, or events for the job

History begins with retained observations, and event names should not be overinterpreted. A new offer event is a first observation here, not proof of an original opening time. A changed event can involve fields other than the numeric line. Compare previous_line and line when you specifically need a movement alert.

Keep freshness visible in the product

Display observed_at beside a line or at the table level, and inspect source_status before sending an alert. Stale data may still be useful for a dated report, but it should not appear as a fresh offer. Partial data can support a clearly scoped view of observed records; it cannot prove that an unobserved player has no market.

This is a developer data product, not a prediction service. A base prop line does not supply sportsbook odds, implied probability, official results, or a recommendation. Promotional flash offers and eligibility are not modeled. If your product needs those concepts, keep them separate rather than deriving them from a number that has a different meaning.

PrizePicks API is an independent data service. It is not affiliated with or endorsed by PrizePicks. Observations, completeness, and freshness are separate claims; consult source status before relying on a stored line.