Contest standings with each entrant's entry count

The contest's entries in finishing order, read from its lineup file: rank, username, points, payout, and how many entries the same user played. Two entries can share a rank; row is the 1-based position and is unique. field states what the field did (roster slots, pool size, C, the field's average lineup and the 3 chalk players), the same for every caller. Access (Frank 2026-09-27, the free flagship model; Frank 2026-10-18, top 100): each marquee contest (GET /api/v1/dfs/marquee: each week's NFL flagship contest, one per operator; each primetime night's single-game flagship, the biggest-prize guaranteed DraftKings pre-game Showdown contest of a Wednesday, Thursday or Monday night; and each NBA night's guaranteed contest with the biggest prize pool at an entry fee of $25 or less on each operator's main slate), free from season 2026 (NBA: from 2026-10-20), opens its first 100 standings rows to everyone, with or without a key (access.plan = "flagship"): those rows, and the full drill-down (every lineup, exposure row, name and value) of every user with an entry in them; no CSV. A row past 100 needs DFS access: such an answer carries the preview envelope _metadata, and a user with no entry in the first 100 rows answers access.locked = true, with or without a key. Any other contest needs a key or a login: no key answers 401 key_required. With a key but without DFS access, any other contest holds the first 5 rows, and only users with an entry in those rows open in the user lineups route (open). Such a capped answer carries the API's preview envelope _metadata (required_tier, message, total_actual_records), as every capped list does; a full answer carries none. CSV needs DFS access (402 otherwise). Each row also carries stack, the combo of that row's own lineup (a row is one lineup entry, not one user) on a classic NFL contest: QB, then the QB's teammates as WR, TE, RB (a count in front when more than 1, as 2WR), then BB for the bring-backs (2BB), joined by /, as QB/WR/RB/BB. It is null when the lineup has no stack and no bring-back, when a seat's position, team or game is unknown (never a partial answer), when the row is not open for the caller, in hide mode, and on every contest that is not a classic NFL contest. The row also carries stack_team, the team of that lineup's QB (the team the stack belongs to, such as DAL), set exactly when stack is set, and bring_back_team, the other team of the QB's game (such as PHI), set only when stack has a BB part. A page draws each team's logo from them. In the CSV the last three columns are stack, stack_team and bring_back_team. 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.