Examples

A box score is one game plus the per-player stat lines for both teams. Find a game in the current season, fetch its player stats, and group them by team.

List endpoints accept whitelisted filter parameters. This example resolves the current season from the API (so it survives the annual rollover) and uses it to filter games.

Every stat-api client reads its key from the STAT_API_KEY environment variable, so a first program is just: construct the client, call a list endpoint, and look at the rows.

Every table exposes an auto-paging iterator that follows the next_from_id keyset cursor until it runs out — so you can consume a whole table without writing the paging loop.

A game log is one player's per-game stat lines with the game context joined back in. Resolve the season, index its games by id, borrow a player from one game's box score, then page that player's stats and join each row to its game.

Grab a team to borrow its id, then list players filtered by team_id — the players endpoint accepts team_id as a filter for both NFL rosters.

season_player_stats holds one row per player per season. Resolve the current season, page through all of it with the auto-pager, then sort client-side to build any leaderboard.

season_team_stats has one row per team per season — wins, losses, games played. Resolve the current season, page the whole table, and sort by wins to build the standings.

A box score is one game plus the per-player stat lines for both teams. Find a game in the current season, fetch its player stats, and group them by team.

The SDK maps status codes to typed errors — AuthenticationError (401), ValidationError (400), NotFoundError (404), QuotaExceededError (429). A 429 is a monthly budget, so it is never retried; branch on the type and handle each.

List endpoints accept whitelisted filter parameters. This example resolves the current season from the API (so it survives the annual rollover) and uses it to filter games.

Every table with a single-column primary key exposes a get(id) that returns exactly one row. Here we list one team to get a real id, then fetch it.

Every stat-api client reads its key from the STAT_API_KEY environment variable, so a first program is just: construct the client, call a list endpoint, and look at the rows.

Every table exposes an auto-paging iterator that follows the next_from_id keyset cursor until it runs out — so you can consume a whole table without writing the paging loop.

Pagination is keyset, not offset. Each list response returns next_from_id — the cursor for the following page — and null on the last page. This is the loop the auto-paging iterator runs for you, written out by hand.

A game log is one player's per-game stat lines with the game context joined back in. Resolve the season, index its games by id, borrow a player from one game's box score, then page that player's stats and join each row to its game.

Every response is metered and stamped with X-Quota-Limit / X-Quota-Used / X-Quota-Remaining. The SDK parses them into a Quota on every list page, so you can watch your monthly budget without a second request.

A rolling average smooths a per-game stat over a trailing window. Fetch a player's game log with the ops, sort it oldest-first, then compute a 5-game trailing average of points — the windowed math the DSL leaves to the escape hatch.

season_player_stats holds one row per player per season. Resolve the current season, page through all of it with the auto-pager, then sort client-side to build any leaderboard.

season_team_stats has one row per team per season — wins, losses, games played. Resolve the current season, page the whole table, and sort by wins to build the standings.

A box score is one game plus the per-player stat lines for both teams. Find a game in the current season, fetch its player stats, and group them by team.

List endpoints accept whitelisted filter parameters. This example resolves the current season from the API (so it survives the annual rollover) and uses it to filter games.

Every stat-api client reads its key from the STAT_API_KEY environment variable, so a first program is just: construct the client, call a list endpoint, and look at the rows.

Every table exposes an auto-paging iterator that follows the next_from_id keyset cursor until it runs out — so you can consume a whole table without writing the paging loop.

Grab a team to borrow its id, then list players filtered by team_id — the players endpoint accepts team_id as a filter for both MLB rosters.

season_player_stats holds one row per player per season. Resolve the current season, page through all of it with the auto-pager, then sort client-side to build any leaderboard.

season_team_stats has one row per team per season — wins, losses, games played. Resolve the current season, page the whole table, and sort by wins to build the standings.

A box score is one game plus the per-player stat lines for both teams. Find a game in the current season, fetch its player stats, and group them by team.

List endpoints accept whitelisted filter parameters. This example resolves the current season from the API (so it survives the annual rollover) and uses it to filter games.

Every stat-api client reads its key from the STAT_API_KEY environment variable, so a first program is just: construct the client, call a list endpoint, and look at the rows.

Every table exposes an auto-paging iterator that follows the next_from_id keyset cursor until it runs out — so you can consume a whole table without writing the paging loop.

season_player_stats holds one row per player per season. Resolve the current season, page through all of it with the auto-pager, then sort client-side to build any leaderboard.

The leaderboards table has one row per player per tournament: rank, total score, earnings, and strokes-gained splits. Pick a golfer and read their finishes.

A scorecard is a round broken into holes. Pick a golfer, index them by id for name lookups, then pull the holes and render score-to-par per hole.

Almost every DFS question starts with one slate id. The main slate is the featured pool for an operator on a day — the full Sunday card in NFL, the full night in NBA, MLB, and NHL. This recipe lists a day's slates and keeps the main one. Every other DFS recipe takes the id it prints.

A slate's player pool is the menu: every player you may roster, each with a salary the operator set before kickoff. This recipe pages the whole pool and ranks it by salary. Slate 129036 is a real DraftKings NFL main slate from 2025-11-30 — swap in the id the main-slate recipe prints.

A fantasy score is a sum, and the parts are what you can model. dfs.player_stats publishes every scoring category as its own column: passing_yds_fpts, rushing_td_fpts, reception_fpts, and 23 more. The raw box-score numbers sit beside them, so you can check the arithmetic yourself. Nothing is nested in JSON, and nothing needs parsing.

Stacking means rostering several players from one game, and it pays when that game turns into a shootout. dfs.game_stats totals the fantasy points every player in a game produced under the slate's scoring rules, split by side, with the real final score on the same row. Ranking a past slate this way shows which games were worth stacking.

dfs.player_stats reports what each player on a slate actually scored under that operator's scoring rules, together with the salary they cost. This recipe ranks a slate by real points. It also shows the trap that catches everyone the first time: a rostered player who never took a snap still returns a row, with every stat null.

Value is points per dollar, and it is the screen that decides most lineups. A 9,800-salary running back who scores 20 points returns less than a 3,600 receiver who scores 15. dfs.player_stats reports the salary and the points on the same row, so this needs one endpoint and no join. Salaries below the floor are excluded, because a minimum-priced player who scores once distorts any ratio.

A team stack is several players from the same offense. dfs.team_stats sums every scoring category over a team's players on one slate, so you can rank offenses directly instead of adding player rows yourself. Each slate game contributes exactly two rows, and each row names its opponent.

Winning lineups are the record of what actually worked. This recipe walks the whole contest chain: pick a contest on a slate, page its lineups, take first place, and read the players it rostered. Each hop uses that endpoint's own required filter, so the chain is the only way through — there is no single call that returns a contest's rosters.

Betting and prediction-market rows reference an underlying event through a polymorphic (league_code, competition_id) pair. competition_id points at a team sport's games.id (or golf.tournaments.id). Here's how to connect a Kalshi market to the NBA game it settles on.

Every endpoint is a GET under https://api.stat-api.com/api/v1/{league}/{table}. Authentication is a single API key sent as a Bearer token. You can explore with the shared trial key right away, then swap in your own key for unrestricted access.