Underdog Fantasy API Options for Pick'em Line Data

If you searched for an Underdog Fantasy API, you probably want Underdog's pick'em lines as structured data: each player, stat and line, readable by a script, so you can line them up against sportsbook player props. Only Underdog can say whether it offers outside developers access to that, and what you'd be allowed to do with it. Its own website, help center and terms are the place to check, and they're the only source worth trusting on the point.

The rest of this page is about the work that sits around that question. Pick'em lines are awkward data to compare with sportsbook prices, and most of the effort goes into matching, timing and payout arithmetic, whichever source you read from.

Why pick'em lines don't drop into a sportsbook schema

A sportsbook prop is two prices on one line: over 24.5 points at -115, under at -105. A pick'em line on Underdog Fantasy or a similar app is usually a line with no price on either side, and the reward is set by how many picks you combine. That gap creates three jobs a sportsbook feed doesn't:

• A missing price has to stay missing. Store null, not -110. A default price quietly turns every line into a coin flip.
• The payout rule is part of the record. The same line is a good pick on one entry type and a bad one on another.
• Alternate lines are separate markets. If an app posts a lower or higher line with a different payout, key it by line type as well as by number.

Matching a pick'em line to a sportsbook prop

The comparison only works when both rows describe the same thing. Match on all of these before you compute anything:

1. Same game, by teams and start time, not by a display name.
2. Same player, through a player id or a checked mapping. Initials and suffixes are where false matches come from.
3. Same stat and period. Points is not points plus rebounds plus assists, and a first-half line is not a full-game line.
4. Same line, or an honest interpolation. If the sharp books sit at 24.5 and the app at 25.5, you either estimate between lines with a stated method or you skip the row.

When any of these fail, drop the row. A missed comparison costs you nothing. A false one invents an edge.

Worked example with a 3-pick entry

Take a hypothetical entry type where 3 picks must all hit and the payout is 6 times the stake. Each pick needs to hit at a rate of one over six, to the power of one third:

Check: 0.5503 x 0.5503 x 0.5503 = 0.1666. Now say sharp books, with their margin removed, give the over a fair chance of 57.0%. The edge per pick is 57.0 - 55.03 = 1.97 points. Three such picks hit together about 0.57 x 0.57 x 0.57 = 18.5% of the time, so the entry still loses more than four times in five. That's what a positive edge on pick'em looks like, and it's why stakes should be money you can afford to lose. The 6 times figure here is illustrative: take real payout tables from the app, because they change.

Reading pick'em lines through ZippyOddsAPI

ZippyOddsAPI is independent and not affiliated with Underdog Fantasy. It reads operators' own public data and returns sportsbook, exchange and pick'em prices in one schema. To see which pick'em apps it knows and their ids, list books by type:

curl -s "https://zippyoddsapi.com/v1/sportsbooks?type=dfs" \
  -H "Authorization: Bearer $ZIPPYODDS_KEY"

That call costs 0 credits. Listing an app there isn't a promise that it's feeding right now: the coverage page shows what is.

Two endpoints then give you the lines, depending on the job:

• /v1/props returns player markets from sportsbooks and pick'em apps together, grouped under the same event. Pick'em apps are in by default; include_dfs=false leaves them out. A pick'em outcome's price is null when the app has none, and market.variant carries the line type (standard, goblin, demon or alternate).
• /v1/dfs scores each full-game over and under against a fair chance from sharp books, with the break-even threshold and the edge when the payout is verified. It takes league, books, priced, limit and cursor.

The ZippyOddsAPI docs also say what the scoring won't do: where an app's payout relationship isn't verified, threshold and edge come back null rather than as a guess, and a row whose fair chance couldn't be worked out gives its reason. The full method and the payout tables used are in the API docs.

Questions for Underdog before you build

Even with data in hand, ask the source these:

• May you store lines and show them to other people, or only use them yourself?
• Are there rate or usage limits on whatever access exists?
• Which states and countries can use the app at all? That changes which lines your users can act on.

PrizePicks raises the same issues with a different payout structure, so the guide to what a PrizePicks API search is really after is a useful companion. On the sportsbook side, see the DraftKings API question, what exists for a FanDuel API, and how to choose a sportsbook API for the props you'll compare against.