Build a sportsbook or embed one? What building from scratch really takes

If you want to know how to build a sportsbook, the short answer is: you need an odds and results pipeline, a market model, a betslip with live acceptance, a settlement engine that can undo itself, a wallet that never moves a balance twice, limits, history and a back office. Industry guides put a custom build at 6 to 18 months and self-builds at well over a million euros. If what you actually need is a play-for-fun sportsbook on your site for your community, with free tokens and never real money, embedding one takes days instead.

How to build a sportsbook: the parts

Here is the component list we'd hand any team that asks how to create a sportsbook app. Each line is a system with its own failure modes.

If you are building for real money, add payments, identity checks, player-protection tooling, licensing and a risk team on top. Those are outside this article, and whether you need them depends on licenses in each country, so take legal advice.

The hard parts nobody mentions

Most guides stop at the feature list, which is the part you can estimate. These are the parts that eat the schedule.

Corrections after settlement

Results get corrected. A goal is reassigned, a match result is amended, a player market is re-graded. When that happens after you've already settled, you have to reverse the first settlement, recover what it returned, and settle again. The player may already have staked what the first settlement returned. You need a policy for a balance that goes below zero, a way to tell every downstream system, and keys that make each generation of the settlement distinct so nothing is treated as a duplicate by mistake.

Half-won and half-lost Asian lines

Asian handicaps and totals on quarter lines split the stake: half the bet is graded on one line, half on the next. The result can be half won or half lost. Inside an accumulator, that leg contributes a partial factor to the combined odds. Get the arithmetic wrong once and your history, your balances and your reports all disagree.

Live prices that move under the player

In play, prices change every few seconds and markets suspend on dangerous attacks, penalties and VAR checks. A live bet needs an acceptance window, then a re-check against the current price and market status, then either acceptance or a clear rejection. The player sees all of this in the betslip, so the UX and the backend have to agree on every state.

Retries and idempotency

Networks fail between "debit accepted" and "response received". If your client retries and your wallet applies the debit twice, you've invented tokens or taken them away. Every balance-moving call needs an idempotency key, a unique index behind it, and the same response on repeats. Placement also needs a compensation path: if the debit went through but the bet couldn't be recorded, something has to give the stake back, exactly once.

Settlement timing and manual review

Most bets can be settled from results within minutes. Some can't: abandoned matches, disputed results, markets with unclear rules. You need a manual review queue and people who understand the rules well enough to grade them consistently.

We know this list well because we've shipped every item on it. The Sportsbook was built by people with seven years of experience building sportsbook software, and most of those years went into the rows above, not the betslip.

Time and cost to build: what published ranges say

We can't tell you how long your build will take. It depends on your team, your scope and your data source. What we can do is show what others publish, with links, so you can check them.

These sources disagree, mix currencies and describe real-money products, so treat them as a spread, not a quote. The pattern is still clear. According to Altenar, building your own costs several times more than any bought option, and every option has ongoing costs, whether that's staff, fees or a revenue share. For a deeper look at how these fees add up, see our guide to white label sportsbook cost.

Two costs the ranges tend to hide:

• Odds and results data. A build still needs a data source. TRUEiGTECH lists odds feeds at $1,000 to $5,000 a month for white labels; a self-build pays for its data directly.
• Staying alive. Leagues change formats, markets get added, sources change their schemas, and corrections keep arriving. A sportsbook is never "done", so budget for the team after launch, not only the build.

Buy: a licensed white label or turnkey

If you are building a real-money betting business, you will almost certainly talk to white label or turnkey providers before you write a line of code. Broadly:

• A white label gives you a branded sportsbook on the provider's platform, often with the provider's license or help getting one, in exchange for a setup fee and a revenue share.
• A turnkey solution gives you more control and usually expects you to hold your own license and run more of the operation.
• A sportsbook module or API plugs a provider's betting engine into your own platform.

We explain the differences, who holds the license and who holds the players in white label vs turnkey vs embedded sportsbooks. If real-money betting is your business, those providers are the right people to talk to. We're not one of them.

Embed: a play-for-fun sportsbook in days

There's a third route that most build-vs-buy articles skip, because it doesn't exist in the real-money world: embed a hosted sportsbook where players stake free tokens.

This fits streamers, communities, fan sites, media, game studios and any site whose users already have points or tokens. You keep your users and your login. The sportsbook runs in an iframe on your page. 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: managed (we keep a record of each balance and you credit tokens through the API) or seamless (your system keeps the balance and we call your endpoint for every movement).

On the server (your API key stays there):

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"}'

On the page:

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

Here is how the build list above maps onto what you get when you embed:

What stays on your side: your login, the page the sportsbook sits on, how players get free tokens (a starting balance, a daily refill, points for taking part), and your community's rules. Our embeddable sportsbook guide covers the whole setup, and the integration docs (opens in a new tab) have the details.

Pricing is public. At the time of writing (September 2026), our plans are:

Prices exclude VAT. Paid plans are a flat price per month or per year; we don't take a share of tokens or of what players stake.

What embedding won't give you: real-money betting, your own trading, custom domains, cash-out or a bet builder. If you need any of those, embedding is the wrong tool.

Build, buy or embed: decision table

A few questions to settle before choosing:

1. Does money change hands? If yes, you're in the real-money world, and the build-or-buy decision starts with licensing advice, not code.
2. Is the sportsbook your product or a feature of your product? Build products. Embed features.
3. Who fixes a corrected result at 2 a.m. on a Sunday? If the honest answer is "nobody", don't build settlement yourself.
4. What do you already have? A community with logins and points makes embedding almost trivial. The odds engine is the part you'd otherwise start from zero on.

If embedding fits, compare the plans and prices, or read how a hosted sportsbook differs from raw data in sportsbook API vs odds API.

Frequently asked questions