Die zwei Auslieferungsmodelle in einfacher Sprache
B2B-Sportsbook-Integration in 2026 kommt in zwei Formen. iframe-basierte Auslieferung: der Operator fügt ein einzelnes <iframe>-Tag in eine eigene Domain ein und der Anbieter liefert die gesamte User-facing Application — Quotenfeed, Wettschein, Cashout, Virtuals, Partner-Panel — aus seiner Infrastruktur. API-only-Auslieferung: der Operator baut sein eigenes Front-End gegen REST-Endpoints + WebSocket des Anbieters.
Beide sind legitim. iframe gewinnt bei Geschwindigkeit, Sicherheitsgrenze und operativer Oberfläche; API gewinnt bei UI-Anpassungstiefe und direkter UX-Telemetrie. Sporbet Soft ist by design ein iframe-first B2B-Sportsbook-iframe. Mehr in unserer Integrations-Anatomie.
Time-to-Launch: fünf Sekunden vs. fünf Monate
iframe-Integration mit Sporbet Soft ist auf einer frischen Test-Domain in unter fünf Sekunden live. Die URL ist mit Ihrem API-Key parametriert, Theming ist eine CSS-Variable-Datei, Custom-Domain ist Self-Service im Partner-Panel.
API-only-Integrationen messen sich in Monaten. Ein typischer mittelgroßer Operator baut mit einem Team von vier bis sechs Engineers (Frontend, Backend, DevOps, QA) vierzehn bis zwanzig Wochen, bevor der erste User auf dem Storefront landet. Bei einem 10-Mio.-USD-GGR-Sportsbook ist die Launch-Verzögerung als Opportunitätskosten messbar — typisch 300–500K USD.
Engineering-Verantwortung
Die iframe-Integration konzentriert die Engineering-Arbeit des Operators auf marken-differenzierende Oberflächen — Affiliate-Hub, BI-Dashboards, CRM, Marketing-Automatisierung. Operator-Engineers berühren niemals Settlement-Code, Quoten-Caching, regulatorische Lokalisierung oder PSP-Retry-Logik.
API-only kehrt das um. Die Engineers des Operators besitzen jetzt eine Kopie des Betting-Front-Ends, die WebSocket-Reconnection-Logik, die Wettschein-State-Machine und Teile des Bet-Validation-Flows. Jede Sporbet-Soft-Pillar-Eigenschaft (Sub-50ms-Quoten-Latenz, deterministisches Settlement, Custom-Domain-Isolation) wird zum Engineering-Deliverable des Operators.
Sicherheitsgrenze
iframe-Integration schafft eine saubere Sicherheitsgrenze an der iframe-Kante. Vendor-JavaScript, Vendor-WebSocket und Vendor-Settlement-Logik laufen in einem separaten Browsing-Kontext, isoliert durch CSP, COOP und X-Frame-Options pro Partner — Details in unserem Custom-Domain-Isolation-Deep-Dive.
API-only verschiebt diese Grenze in die Operator-Application. Der Quotenfeed des Anbieters landet im JavaScript-Runtime des Operators. Die Blast-Radius einer UI-Schwachstelle umfasst nun Operator-PSP-Keys, Operator-Session-Cookies und alle First-Party-Analytics-Tags.
Total Cost of Ownership: die Fünfjahres-P&L
Bei einem 10-Mio.-USD-GGR-Sportsbook ist die Fünfjahres-TCO von iframe-Plattform vs. API-only-Build nicht knapp. Fünf Jahre Sporbet Soft zur pauschalen 1.500-USD-Monatsgebühr — siehe vollständige Mathematik unter Sportsbook-Preise — sind 90.000 USD Anbieter-Kosten total.
API-only auf demselben Workload erfordert typischerweise vier bis sechs dedizierte Engineers im ersten Jahr. Bei voll geladenen Kosten von 120K USD pro Engineer in EMEA: 400K bis 700K USD pro Jahr nur für Engineering, plus Vendor-API-Plattformgebühren von zusätzlich 300–600K USD/Jahr.
Fünfjahres-TCO: Sporbet Soft iframe 90K USD vs. API-only 3,5M–5M USD. Die Lücke ist so groß, dass sie den Headcount-Plan des Operators verändert.
Wann API-only tatsächlich richtig ist
Wir sind nicht religiös in Sachen iframe. API-only ist richtig für: Tier-1-Operatoren mit 50+ Engineers; regulierte-Markt-Operatoren, deren Lizenzbedingungen Operator-Eigentum der User-facing Application erfordern; Multi-Vertikal-Operatoren (Casino + Sportsbook + Lotterie), die die Betting-Oberfläche in eine maßgeschneiderte UI konsolidieren.
Für alle anderen — Affiliates auf dem Weg zum Operator, Casino-First-Operatoren mit Sportsbook-Ergänzung, regionale Buchmacher, Start-ups, Markennetzwerke — ist iframe die richtige Antwort. TCO-Mathematik, Sicherheitsgrenze, Time-to-Launch und Engineering-Verantwortung zeigen alle in dieselbe Richtung.