Streams or renders full contest lineups including complete player pool, ownership metrics, exact seat selections, and fantasy points. Supports on-the-fly CSV generation (?format=csv) or streamable gzipped JSON (?format=json).

CSV Lineup Slot Format: Each lineup roster cell is formatted with player metadata and slot-specific ownership: "<Player Name> (id: <export_id>, salary: <salary>, fpts: <fpts>, own: <slot_own>%)"

• Showdown / Single Game: Captain/MVP slot displays Captain ownership (cpt_field_pct); FLEX slots display Flex ownership (flex_field_pct).
• Several multiplied slots (FanDuel NBA MVP/STAR/PRO, MLB MVP/STAR): each multiplied slot displays the share of lineups that hold the player in that slot, and the UTIL slots display the share that hold him in a UTIL seat. A cell shows the points of the player's row for its slot.
• Classic Multi-Game: All slots display tournament field ownership (field_pct).
• Each cell shows the id, salary and points of the player's player_pool row for that slot (the CPT/MVP row on the first seat of a single-game lineup).
• A value the data does not hold is left out: an unresolved player's cell reads "(id: <export_id>, own: <slot_own>%)".
• A removed-player seat (the operator took the player off the slate after users drafted him) reads "<operator's name> (id: <negative capsule-local id>, fpts: <operator's table points>, own: <slot_own>%, canonical_player_id: <our player id>, is_removed: true)": no salary and no upload id.
• A shared-name seat (the operator's own player pool gives the name to two players of one position, and its contest file names no id) reads "<operator's name> (id: <negative capsule-local id>, fpts: <operator's table points>, own: <slot_own>%, is_shared_name: true)": no player id of any kind, no salary and no upload id.

CSV Stat Enrichment (enrich=dfs.player_stats): When enriched with dfs.player_stats, non-zero boxscore counting stats are nested directly inside each slot cell: "<Player Name> (id: <export_id>, salary: <salary>, fpts: <fpts>, own: <slot_own>%, dfs.player_stats: [<stat_1>: <val_1>, ...])"

Example (Showdown Enriched Lineup): "Patrick Mahomes (id: 112411-57439, salary: 15000, fpts: 45.15, own: 1.97%, dfs.player_stats: [passing_yds: 245, passing_tds: 1, rushing_yds: 43, rushing_tds: 1])","Josh Allen (id: 112411-62239, salary: 17000, fpts: 21.38, own: 2.12%, dfs.player_stats: [passing_yds: 237, passing_tds: 2, rushing_yds: 39, fumbles_recovered: 3])"

202 Accepted (the lineup file is not loaded yet): A caller with a paid plan (not a trial key) who asks for a DraftKings contest that has started and has no lineup file gets 202 and no lineups, and the API queues a load of the file. A 202 costs no record. It carries Retry-After (seconds) and Cache-Control: no-store, and its body is JSON whatever format asks for:

{"status": "queued", "message": "The lineups of contest 196420231 are not loaded yet. A request to load them is queued. Expect them by the time in estimated_ready_at. Call again in 120 seconds.", "contest_id": 29647259, "external_id": 196420231, "requested_at": "2026-10-12T02:26:11Z", "estimated_ready_at": "2026-10-12T02:42:00Z", "retry_after_seconds": 120, "entry_count": 340}

status is queued (the loader will load the file; estimated_ready_at is the time to expect it) or waiting_for_contest (the contest has not finished; estimated_ready_at is then null). Call again after retry_after_seconds.

A caller on a free plan, on a trial key or with no key never gets a 202: it keeps the answer it had before (a 200 with no lineups, or the preview).

A contest that will never have a file answers 404 (lineups_not_collected: the loader does not collect lineups for this contest), 410 (lineups_file_gone: DraftKings no longer serves the file) or 503 (lineups_not_loaded: the loader gave up and support is informed), each in the usual error body.