Fliff Odds API

Most US sportsbooks are licensed state by state, which means the set of books available to a bettor changes depending on where they open the app. Fliff runs on a different model and reaches users that the state-licensed operators often cannot.

That is the reason to carry it. Not because it adds another line to an already crowded moneyline, but because for some users it is one of the few prices they can actually act on.

What that means for a comparison product

If you are building odds comparison for a national audience, the honest version of the product is not "here are twenty books". It is "here are the books available to you". Those are different lists in different places, and a book operating outside the state-licensed model sits in a different bucket from DraftKings or FanDuel.

Two practical consequences.

The first is that a price you can read is not always a price your user can take. That is true of any book with limited availability, and it is worth handling in your interface rather than assuming the whole board is actionable. The BetOnline Odds API page makes the same point from the other direction, for a book whose reach is global rather than state-shaped.

The second is more interesting for anyone doing analysis. A book serving a different population is not simply echoing the same money as the licensed majors. Where its number differs from the consensus, that difference is information rather than noise.

Requesting Fliff prices

Filter to Fliff alone with bookmakerID=fliff:

curl "https://api.sportsgameodds.com/v2/events?leagueID=MLB&bookmakerID=fliff&oddsAvailable=true" \
  -H "x-api-key: YOUR_API_KEY"

More usefully, request it next to the books you are comparing it against:

curl "https://api.sportsgameodds.com/v2/events?leagueID=MLB&bookmakerID=fliff,draftkings,fanduel,betmgm&oddsAvailable=true" \
  -H "x-api-key: YOUR_API_KEY"

Every book comes back on the same oddID, so lining the prices up is a lookup rather than a matching problem.

What a Fliff price looks like

{
  "eventID": "...",
  "leagueID": "MLB",
  "odds": {
    "batting_totalBases-PLAYER_ID-game-ou-over": {
      "oddID": "batting_totalBases-PLAYER_ID-game-ou-over",
      "marketName": "Total Bases Over/Under",
      "statID": "batting_totalBases",
      "statEntityID": "PLAYER_ID",
      "periodID": "game",
      "betTypeID": "ou",
      "sideID": "over",
      "fairOdds": "-118",
      "fairOverUnder": "1.5",
      "bookOdds": "-125",
      "byBookmaker": {
        "fliff": { "odds": "-115", "overUnder": "1.5", "available": true },
        "draftkings": { "odds": "-130", "overUnder": "1.5", "available": true }
      }
    }
  }
}

Odds and lines are both strings, so -115 arrives as "-115" and "1.5" stays a string rather than becoming a float you have to guard against. fairOdds is the vig-free consensus across every book pricing that market and bookOdds keeps the margin in, which gives you a benchmark without computing one.

Which plan includes Fliff

Fliff is available on the Rookie plan and above. The free Amateur tier carries a shorter list of nine books that does not include it, so a request filtered to fliff on that plan returns an empty result rather than an error. Pricing lists the books on each tier.

Coverage, honestly

Fliff does not price everything, and no single book does. Read byBookmaker on each odd rather than assuming it is there, and treat its absence as normal rather than as an error. The /markets endpoint returns the supported set by league if you would rather check before requesting odds than handle it at runtime.

Coverage is not static either. Books add and drop markets, so anything you hardcode is a bug waiting for a quiet week.

Use cases for Fliff data

Odds comparison is the direct one, with the caveat above: showing a price is only useful if your user can act on it, so availability belongs in the interface rather than being assumed.

For positive EV work, a book pricing to a different population is a genuinely separate opinion rather than another copy of the same consensus. That is worth more to a model than a book that follows the majors.

Arbitrage tools find books outside the main cluster on one leg more often than their size suggests, for the same reason — they are not watching the same competitors as closely.

Fliff API technical specifications

Fliff comes through the standard /v2/events endpoint, with no separate call, credential or schema for any individual book.

Billing is per event object rather than per market or per book, so a ten-game slate is ten objects whether you ask for Fliff alone or Fliff alongside eighty others. Adding books to a request you were already making costs response size and nothing else.

Odds refresh sub-minute on Pro, with a longer interval on Rookie. The API documentation covers authentication, pagination and the full parameter list, and handling odds covers reading byBookmaker in code.