Sportsbook API vs odds API vs betting widget: what do you actually need?

A sportsbook API, an odds API and a betting widget are three different products that show up for the same searches. An odds API sells you raw prices and leaves everything else to you; an odds widget displays those prices on your page; a hosted sportsbook with a session and wallet API gives your users a place to actually bet, with settlement and history already done. Pick by what you want your users to do: read prices, or place bets (on a play-for-fun sportsbook like ours, with free tokens and never real money).

Three different products, one search term

"Sportsbook API" gets typed by very different people. A developer building a pricing model wants a feed of lines from many books. A media site wants odds next to its match previews. A community owner wants members to bet on Saturday's games with the site's own points. All three search the same words and land on the same pages, most of which are selling the first product.

The confusion is understandable, because each of these products has "API", "odds" and "sportsbook" somewhere on its homepage. The useful question is what you receive when you integrate:

The rest of this article goes through each one and what it leaves on your plate.

Odds APIs: raw prices, you build everything else

An odds API (also sold as a sports betting API or betting odds API) returns markets and prices for fixtures, usually pre-match and in-play, sometimes from several bookmakers side by side. You poll it or subscribe to a stream, and you get numbers.

That is exactly what some projects need. Line-shopping tools, odds comparison sites, betting models, research dashboards and trading tools all want the raw prices and nothing else. For them, a hosted sportsbook would be in the way.

What an odds API does not give you is a sportsbook. If you want users to bet, you still have to build:

• A market model and UI. Mapping feed markets into something a person can read, per sport, including handicaps and totals.
• A betslip. Singles and accumulators, combined odds, stake validation, price-change handling.
• Acceptance. Live prices move. You need a short acceptance window and a re-check against the current price before a live bet stands.
• Balances. A ledger per user, with idempotent debits and credits so a retry never moves tokens twice.
• Results and settlement. A second data source for results, grading logic for every market type, voids, and half-won or half-lost Asian lines.
• Re-settlement. Results get corrected after the fact. You need to reverse the old settlement and apply the new one without breaking balances.
• Limits, history and an admin panel. Stake limits, a bet history for players, and a back office to see what happened.

We go through each of those parts, and what they cost to build, in build a sportsbook or embed one. The short version: the odds feed is the smallest line in the project.

Odds widgets: display only, usually paid for with bookmaker links

An odds widget (or sports betting widget, in its display-only form) is a block of HTML or a script tag that shows current prices on your page. Some are free up to a traffic cap, some are paid, and many are built for affiliate publishers: each price links out to a bookmaker, and the widget or the site earns when a visitor signs up there.

For an affiliate site, that is the whole point. For almost anyone else, a widget has two limits. First, nobody can bet in it, so it gives visitors something to look at, not something to do. Second, the business model around it is bookmaker referrals, which may not be what you want next to your brand.

That second point matters if you are considering The Sportsbook. Our play-for-fun rules (AUP 6.1(b)) forbid bookmaker links, affiliate links, promo codes, odds boosts, bonus offers and operator branding in or around the embed. You can't put an odds widget with bookmaker links next to the sportsbook, and you can't use the sportsbook to send players to one.

A sportsbook API for a hosted sportsbook: sessions and balances

The third product is a sportsbook someone else runs, which you place on your site. The "API" here is not a data feed. It is the small set of server calls that connect your users to it.

With The Sportsbook, the integration is three steps:

1. Your server opens a session for the logged-in player with your API key and gets a single-use launch_url.
2. Your page loads the SDK and mounts the sportsbook with that URL.
3. Your server manages token balances, either through our API (we keep a record of each balance) or through your own endpoint (we call it for every token movement).

The session call is one request:

curl -X POST https://api.thesportsbook.app/b2b/v1/sessions \  -H "Authorization: Bearer $SPORTSBOOK_API_KEY" \  -H "Content-Type: application/json" \  -d '{"user_ref": "viewer-42", "display_name": "Viewer 42", "locale": "en"}'

And the page needs two lines:

<div data-thesportsbook data-launch-url="LAUNCH_URL_FROM_YOUR_SERVER"></div><script src="https://play.thesportsbook.app/sdk.js"></script>

Everything behind that iframe is done: match lists, the market list we carry for each match, the betslip with singles and accumulators, live acceptance with a price re-check, six odds formats, English and Spanish, and a bet history per player. Odds, results and settlement come with the platform. Most bets settle minutes after the final whistle; a few wait for official results or a check by our team. If a result is corrected later, the bet is re-settled and your wallet is told.

The rest of the API is about your players and their tokens: crediting a starting balance, reading a balance, reading a player's bets (rounds), and summary reports in token terms. There is no endpoint that returns a price feed, because the sportsbook isn't a data feed. Our policy (AUP 10.2(a)) forbids scraping, extracting, caching, storing, redistributing or reselling the sports data shown in the embed, or using it to build another product or model.

For the technical detail of sessions, events and auto height, see the sportsbook iframe integration guide.

What you build or maintain in each case

Prices for The Sportsbook at the time of writing (September 2026): Free at $0 with one sport, up to three leagues and pre-match betting; Custom from $49 a month; Full at $490 a month. Details on the pricing page.

When an odds API is the right answer

Choose an odds API when the prices themselves are the product:

• You are building an odds comparison, line-shopping or arbitrage tool.
• You run a betting model and need historical and current lines to train or test it.
• You publish analysis that quotes prices from several books.
• You are a licensed real-money operator building your own sportsbook and have the team to write settlement, risk and wallets. In that case a real-money sportsbook provider or a data feed is what you evaluate, not a play-for-fun product.

In all of these, a hosted sportsbook is the wrong tool. You can't pull its data, and you don't want its betslip.

When an embedded sportsbook is the right answer

Choose a hosted, embedded sportsbook when the goal is that your users bet, and you have no interest in building a betting engine:

• Communities and creators with their own site, points or tokens, who want members to bet on matches together. The embeddable sportsbook guide covers the whole model.
• Media and fan sites that want readers to stay through the match instead of leaving after the preview. See a play-for-fun sportsbook for sports media and fan sites.
• Game studios and apps that want sports events as live content, with a separate free token balance. The guide to an in-game sportsbook for studios covers the currency rules.
• Teams that already priced out a build and found that settlement, corrections and wallets are most of the work.

A few questions settle it quickly. Do your users need to place bets, or only see prices? Do you have logged-in users you can identify on your server? Are you happy for balances to be free tokens with no cash value? If the answers are "place bets", "yes" and "yes", an embedded play-for-fun sportsbook will get you there in days. If you need raw data, or real-money stakes, it won't, and one of the other two products is the honest recommendation.

The quickest way to judge is to use one. The live demo (opens in a new tab) runs the real embed with free demo tokens and no sign-up, and the home page has the overview.

Frequently asked questions