The two delivery models in plain language

B2B sportsbook integration in 2026 still arrives in two shapes. iframe-based delivery means the operator pastes a single <iframe> tag onto a domain they own and the vendor serves the entire user-facing application — odds feed, betslip, cashout, virtuals, partner panel — from the vendor's infrastructure. API-only delivery means the operator builds their own front-end, integrating against the vendor's REST endpoints for catalogue and account management plus a WebSocket connection for live odds and ticket events. The vendor never serves user-facing pixels.

Both are legitimate. iframe wins on speed, security boundary and operational surface; API wins on UI customisation depth and direct ownership of the user-experience telemetry. We have shipped both at our integration anatomy article, and the choice is rarely about technology — it is about who owns the product roadmap.

Sporbet Soft is an iframe-first B2B sportsbook iframe by design. The five-second integration commitment, the flat pricing and the operator-grade controls all assume the operator wants velocity over surface ownership. That alignment is not for every operator — but it fits the majority who are not building betting interfaces in-house.

Time-to-launch: five seconds vs. five months

The most quotable difference is launch time. An iframe paste-and-go integration with Sporbet Soft is live on a fresh test domain in under five seconds — the URL is parameterised by your API key, theming is one CSS variable file, custom domain is self-service in the partner panel. We have onboarded operators who went from contract signature to a working storefront on their own domain in the same business day.

API-only integrations measure in months, not days. A typical mid-sized operator builds against the vendor's REST + WebSocket surface with a team of four to six engineers (frontend, backend, devops, QA) for fourteen to twenty weeks before the first user lands on the storefront. Add another six to eight weeks for the long-tail of bet builder, cashout UX, virtual sports embedding and risk-tool dashboards. Five months is the conservative midpoint.

On a sportsbook that will eventually do US$10M of GGR, the launch-delay opportunity cost is measurable. Each week before launch is one week of marketing budget unspent and one week of competitor mind-share captured. We have seen API-only operators write down US$300–500K in launch-delay costs before opening a betslip.

Engineering ownership: where do your engineers spend their time?

An iframe integration concentrates the operator's engineering effort on the surfaces that differentiate the brand — affiliate hub, BI dashboards, CRM integrations, marketing automation, native mobile wrapper. The operator's engineers never touch settlement code, odds caching, regulatory localisation or PSP retry logic. Those are vendor problems.

API-only inverts this. The operator's engineers now own a copy of the betting front-end, the WebSocket reconnection logic, the betslip state machine, the cashout pricing UX and (depending on the vendor) parts of the bet validation flow. Every Sporbet Soft pillar piece (sub-50ms odds latency, deterministic settlement, custom-domain isolation) becomes an operator engineering deliverable. We have nothing against operators who want this — but it is a hire-and-retain commitment for the life of the contract.

Sporbet Soft's view: the operator's CTO should be optimising for time the engineering team spends on operator-specific surface, not vendor-specific plumbing. The iframe model collapses the plumbing to a single tag.

Security boundary: who is in the blast radius?

Iframe-based integration creates a clean security boundary at the iframe edge. The vendor's JavaScript, the vendor's WebSocket connection and the vendor's settlement logic execute in a separate browsing context isolated by CSP, COOP and X-Frame-Options scoped per partner — covered in detail in our custom-domain isolation deep-dive. A compromise inside the iframe cannot exfiltrate cookies from the operator's parent page, and the parent page cannot tamper with the vendor's betslip state. PCI-relevant surfaces never live in the operator's domain at all.

API-only integration moves that boundary up into the operator's application. The vendor's odds feed lands in the operator's JavaScript runtime, the operator's CSP must allow the WebSocket origin, and the operator's audit trail must capture every settlement event for compliance. The blast radius of a UI vulnerability now includes the operator's PSP keys, the operator's session cookies and any first-party analytics tagging on the page.

For operators in regulated markets (UK, MGA, Sweden, Australia, Ontario), this is more than aesthetic. The auditor will read your CSP, your COOP headers and your data-export endpoints. With Sporbet Soft's iframe model, most of that surface lives on our side of the boundary — for an API-only build, all of it lives on yours.

Customisation depth: what you give up with iframe

iframes are not infinitely customisable. The Sporbet Soft iframe ships with a CSS variable file the operator edits in the partner panel — colours, radii, fonts, header height, button styles — plus optional per-route theming for the homepage, betslip and live module. That covers about 90% of the brand-specific styling operators actually want.

What it does not cover: bespoke betslip layouts, novel game types the vendor has not built, or operator-specific information architecture (e.g. surfacing a customer's local football league above the global default). For those use cases API-only is the right answer. Operators with brand teams that have strong opinions about every pixel — and the engineering budget to implement them — should choose the API model.

Sporbet Soft's iframe is also extensible via postMessage: operators can listen for betslip events, ticket settlements and cashout windows from the parent page and react in their own UI (open a deposit modal, fire an analytics event, route to support). That is enough integration for most operator pipelines without owning the entire surface.

Total cost of ownership: the five-year P&L

On a US$10M-GGR sportsbook, the five-year TCO of an iframe-based platform versus an API-only build is not close. Five years of Sporbet Soft at the flat US$1,500 monthly fee — see the full math at sportsbook pricing — is US$90,000 in vendor cost. Operator engineering cost over the same window for the surfaces the iframe owns is effectively zero, because the iframe absorbs them.

API-only on the same workload typically requires four to six dedicated engineers for the first year and two to three for ongoing maintenance, plus a portion of devops and QA capacity. At a fully loaded cost of US$120K per engineer in EMEA, that is US$400K to US$700K per year on engineering alone — before the vendor's API platform fee, which on tier-1 contracts often runs an additional US$300–600K per year.

Five-year TCO comparison: Sporbet Soft iframe at US$90K total versus API-only at US$3.5M–5M total. The gap is so large it changes the operator's headcount plan. Operators who switch to iframe routinely redeploy two of those engineers to growth-side product (affiliate analytics, CRM integrations) and net-out faster.

When API-only is actually the right choice

We are not religious about iframe. There are operator profiles where API-only is the right call: a tier-1 operator with 50+ engineers and a mature betting product team that wants the entire surface; a regulated-market operator whose licence terms require operator ownership of the user-facing application; a multi-vertical operator (casino + sportsbook + lottery) consolidating the betting surface into a single bespoke UI.

For everyone else — affiliates becoming operators, casino-first operators adding sportsbook, regional bookmakers, startups, networks consolidating brand presence — iframe is the right answer. The TCO math, the security boundary, the time-to-launch and the engineering ownership all point in the same direction.

What to ask before you commit

If you are still on the fence, three concrete questions narrow the decision. How fast does the business need to launch? Anything under three months effectively requires iframe — API builds do not deliver that fast even with experienced teams. How differentiated is the betslip UX vs. the rest of the operator's value proposition? If the betslip is brand-critical, API-only is the model. If your differentiation is markets, marketing or operations (typical), iframe is fine. How many sportsbook engineers can you hire and retain for five years? If the honest answer is less than three, the iframe absorbs the gap; API-only operators with under three sportsbook engineers degrade fast.

Operators who answer those three questions out loud almost always land on the same shape. The iframe-first B2B sportsbook iframe Sporbet Soft ships is built for that majority. If you fall in the API-only bucket, we will tell you and recommend an API-first vendor — better that than three years of buyer's remorse on either side.