The Integration Is Part of the Product

Michael Cheremuhin, CTO, B1 (Be One, formerly Betbazar)

Sportsbook technology is usually evaluated by what it delivers: coverage, speed, markets, features. I have that slide too. But after years of building high-load systems and plugging them into operators' platforms, I have learned that another factor decides whether any of those advantages matter at all: how the product actually gets into production.

‍

The real work starts after "yes"

A product can look perfect during evaluation. The commercial case makes sense, the technical requirements look manageable, the documentation is ready, both sides agree to move forward.

Then integration starts. This is where assumptions meet infrastructure.

Here is what day one usually looks like. The operator's developer gets a document, a sandbox login and a JSON example of a market message, and starts coding against it. Three days later the questions begin:

• "The example shows the status as a string. In the feed it's an integer. Which is it?"
• "A market that was in the last message is missing from this one. Suspended, closed, or did you drop a packet?"
• "We got a message with an empty body. Is that a bug?"
• "Your example has 14 fields. Production has 19. Do we ignore the extra ones?"

None of these are hard problems. Each one costs a day, because the developer has to ask, someone on the provider side has to find the person who knows, and the answer travels back through an account manager. Twenty questions like that and a month is gone before a single bet has been priced.

Every operator is different. One has a large engineering team and a mature platform; another has two developers and a legacy sportsbook. One wants a full migration; another wants one new content category without touching anything else. Yet integrations are still too often approached as if sending API documentation is the beginning and end of the provider's responsibility.

I strongly disagree with that model. The operator never experiences "the feed". They experience the feed plus every hour their engineers spent guessing at it. Integration is not what happens before the product starts working. Integration is part of the product.

‍

The biggest gap isn't technical

The most persistent integration problem I see is simple: business and development describe the same requirement in different languages.

Business says: we want to add this content.

Development needs to know: what does that mean in the feed? Which structures change? Which market types appear? What has to be mapped? What happens to the existing settlement logic?

The wider the translation layer between those two conversations, the more room for mistakes. And with sports data the gap is bigger than it looks, because live and pre-match are different engineering problems.

Pre-match is about depth and stability. Markets exist for days or weeks before an event; a mistake is visible and fixable.

Live is about time. Prices change continuously, markets suspend and reopen, and an update loses its value in seconds. A market that stays open with a stale price is not a bug, it is a payout.

Pre-match earns the operator's trust. Live earns their revenue. The integration has to understand both realities; it cannot just move data from A to B.

‍

Speed isn't just latency

The industry loves latency numbers. They fit on a slide and they are easy to compare.

But there are two speeds that matter. System speed is how fast information travels from trading infrastructure to the operator. Integration speed is how fast the operator can turn that technology into something live in production.

You can optimise the first down to milliseconds and still lose weeks on the second: responsibilities unclear, documentation out of date, problems bouncing between commercial, integration and engineering teams.

That is why I think a provider should treat every integration as a small product launch of its own. Understand the client's architecture first. Decide what actually needs integrating. Bring technical people into the conversation early, before the contract, not after. Test against real structures rather than idealised examples. Agree who owns each kind of problem before that problem exists.

The goal is not to integrate faster. It is to remove work from the operator's side.

‍

Documentation should describe reality, not history

Documentation is necessary and increasingly insufficient.

A live feed changes constantly. Data structures evolve, new markets appear, new content is introduced. A document is a snapshot of what an engineer believed on the day they wrote it, and from that day it drifts. The moment it disconnects from the system, developers are integrating against an abstraction of the product instead of the product they will actually receive. That is where the four questions above come from.

I think the next generation of integration tooling closes this gap. Instead of a static document being the main interface between two engineering teams, operators should be able to work with environments and tools that understand the actual data structures, configuration and logic of the feed they are about to receive, as it is today, not as it was in the spring.

AI has a real role here. Not as a chatbot bolted onto a PDF, but as a way to strip out the repetitive translation and investigation engineers currently do by hand: what does this field mean, what changed, what does this key decode to. Most operators' developers already have an AI coding agent open. The question for a provider is what that agent gets to read.

‍

Design for failure before production

Another common mistake is treating reliability as something to address after launch.

Every infrastructure component will have a bad day. A data centre fails, a network route degrades, a service slows down, an upstream source behaves unexpectedly. The engineering question is not whether failure is possible. It is what the system does next.

My rule for any new integration: the first thing you wire up is the failure path. Heartbeat monitoring, so the operator knows within seconds that the feed is down and can suspend affected events. Reconnect logic. A test that the watchdog goes down and comes back up. Only then do you touch a price.

That feels backwards to people who want odds on a screen by Friday. It isn't. The failure path is the product; the happy path is the demo.

The same logic applies to support. Automation should detect anomalies, monitor runtime metrics and escalate immediately. But when an operator needs an explanation or a decision, that conversation needs a person who understands what is actually happening.

Machines watch the system. People talk to clients. Doing it the other way round, engineers staring at dashboards while customers explain their problem to a bot, is a remarkably inefficient use of both.

‍

Why this matters more when the sport is not real

We now run AI sports: matches generated by an agent-driven game engine with no scripted outcomes, priced by automated trading that runs independently of the engine and updates odds in under 50 milliseconds. Every AI sport streams in parallel, all day, every day.

There is no off-season and no fixture list. There is no "let's wait for Saturday to test". An operator integrating this content is integrating a system that never stops, and a slow leak in the integration - a market state that drifts, a settlement that mismatches when an event is interrupted - shows up in hours, not weeks.

That has made us ruthless about the integration path. There is no version of this product that works with "here is the API doc, good luck". It only works if the provider owns the integration as seriously as the feed.

‍

A successful integration should become boring

There is a tendency in technology to celebrate complexity. I prefer the opposite.

The best integration is one the operator eventually stops thinking about. Data arrives when expected. A market that disappears is closed, not orphaned. Configuration changes do not need an engineer. Problems are detected before they become commercial incidents. And when something unusual happens, everyone knows who owns it.

That takes sophisticated engineering underneath. But the sophistication should be the provider's problem, not the client's experience.

We talk about the quality of sportsbook technology in terms of what it can do. We should pay far more attention to how much work it creates for the people using it. A technically excellent product that takes months of friction to integrate, needs constant manual intervention and becomes one more system the operator has to babysit is not solving the problem. It is creating a new one.

That is why, for me, the integration will always be part of the product.

‍

Michael Cheremuhin
CTO, B1 (Be One, formerly Betbazar)

Michael Cheremuhin is CTO at B1, an iGaming technology company building real-time sports data feeds and AI sports products. With a background in high-load systems, he focuses on sportsbook infrastructure, data architecture, integration, automation and technology designed for continuous real-time operation.

Read the full article on the industry media