API-First – control without compromising the core

“API-first” has become a widely used term in platform technology. What does a genuinely API-first iGaming platform look like in practice, and how does it differ architecturally from a traditional platform with APIs added around the core?

Comtrade Gaming was originally a software technology solution provider, and our product was made from the knowledge we accumulated working for the gaming industry. But we also worked for enterprises and governments, in a lot of different domains, so we were always oriented toward industry best practices. Different teams were working with different practices, standards and new ideas.

For example, working on government projects like document handling taught us how important auditing is, how different formats interchange, how versioning of documents works, how regulation changing affects the product etc. That explains why our product has been built as it was: to layer properly, use interfaces inside the code, component design, separating database etc.

That matters because API-first is very hard to add later. If the inside of a platform is one big block, any API in front of it stays a thin wrapper, and the vendor’s own tools keep going around it. In iCore, our own back office and player portals use the same APIs we give operators. Modules like tournaments, jackpots and campaigns run as separate services and talk to the core through APIs and events.

Not every part of a platform with this much history is equally modern. The newer layers follow these principles most fully, and we keep moving older services forward behind stable contracts.

One of the promises of API-first architecture is that operators can innovate without rebuilding their underlying platform. Which parts of the technology stack can realistically be changed or replaced independently, and where do dependencies on the core still remain?

Most of what sits around the core. The front end, engagement modules like tournaments and jackpots, and the providers behind our integration adapters can all change without the core noticing. Systems like a CRM or a data warehouse can subscribe to our events instead of reading our database. What stays in the core is the wallet, player accounts and the regulatory controls. Regulators audit exactly those parts, and in some markets, they’re certified down to the file hash, so changing them means going through certification again.

How does an API-first approach change the process of integrating new game suppliers, payment providers, CRM tools, KYC solutions or other third-party technologies? Where are the biggest integration bottlenecks today?

The integration work itself has become fairly routine for us. We’ve done more than a hundred casino integrations and about as many on the service side. Each category has its own template, with the standard wallet or payment contract, signature handling, a simulator and tests, so a new game provider is mostly a matter of mapping their API onto ours. Lately we’ve also used AI to generate the first version of an integration from the provider’s documentation, with our engineers checking each step, and that has made the coding part a lot shorter.

Where it still slows down is usually outside the code. Provider documentation is often incomplete or doesn’t match what their API actually does, and difficult cases like rollbacks only show up in testing. Then there’s the provider’s own certification and the regulator in each market, and neither runs on our timeline. Once an integration is finished we package it as an AddOn, so the next operator who wants that provider gets it through configuration.

Operators increasingly want differentiated frontends rather than experiences dictated by their platform provider. How much freedom can an API-first platform give them to build custom web and mobile experiences while retaining a stable backend?

We already have different scenarios with our clients. Some own their own player UI team, some employed external companies and some also use our team for the player portal. So we had to be prepared for a lot of different requirements and scenarios.

One client wanted to move implementation of the portal from our team to theirs and also to switch the technology used, so we had two different portals for months in parallel. Even though we had clear separation between UI and core logic, it pushed us to split even more. And to avoid a lot of questions we provided Swagger and an AI agent to help their team to integrate. Also every customer wants to have a distinguished portal with recognisable functionality. That was the start of web components provided for some functionality to the portal.

Everything runs through one contract, our Portal Gateway, which is a versioned API with a published OpenAPI specification for each operator. Each operator’s gateway is built from the same standard core, plus the modules they use and their own extensions.

APIs evolve continuously, but operators cannot afford integrations to break every time a platform is updated. How do you approach API versioning and backwards compatibility while still allowing the technology to move forward?

We had to learn this lesson the hard way. We had a client with many different teams integrating to our system. One requested a quick change, another hadn’t time to adapt. The plan was to have one big bang release all together, so when the second team didn’t finish we were under pressure from both teams. One to push the release, another to postpone. But this was a valuable lesson that helped us include versioning thinking everywhere. It was at the beginning, when we had one main customer view. Now we can handle multiple different customers on the same code.

In practice, our player API carries the version in the URL of every endpoint, and old and new versions run side by side. A change that would break existing clients goes into a new version, and the old one stays as it is until the client is ready to move. Adding fields or new endpoints happens in the current version, because that doesn’t break anyone. Our own back-office front end is generated from the same API contracts, so we’d feel a breaking change before any operator did.

And, my opinion, we also skip the versioning hell, as we are pushing customers to the same version. And they accept that because they don’t notice problems or have any extra work.

Does giving operators greater control over their technology choices create a new challenge around complexity? At what point does flexibility risk producing a fragmented stack that becomes harder to maintain and operate?

It can. In the early years, when we still built mostly around one main customer, customer-specific work slowly made every release heavier, and that’s part of why we’re strict about it today. Operator-specific behavior goes into defined extension points, such as customer layers in the gateway or installable AddOns, and never into a fork of the core. What I look at is whether an operator can take our next release without a project around it. Every component someone adds also needs monitoring and an owner.

What role do documentation, developer portals, sandbox environments and testing tools play in an API-first model? How important is the developer experience when operators or third parties are building directly against your platform?

Simulators are actually part of almost every project. It is better now, but when we started years ago, getting an integrator’s test system was time consuming. We couldn’t wait with implementation and testing, so we had to build them. Or I could say they saved a lot of our projects, if not most.

Beyond that, we publish OpenAPI contracts for our APIs, there’s an integration guide for the player API, and the provider APIs come with Postman collections. When a client’s portal team took over front-end development, we also gave them an AI agent that knows our API, so they could get answers without waiting for our engineers. Every operator has QA environments, and we load-test each release against that operator’s traffic profile. Where we want to improve is self-service. Today a new partner still needs some contact with our team to get started, and we’d like them to be able to get a sandbox and make their first calls on their own.

As more functionality is exposed through APIs, how do you manage security, authentication, permissions and data access without creating friction for operators and their technology partners?

We try to keep the rules the same everywhere. Applications identify themselves with a key. Players get signed tokens that we check against their live session on every call. Back-office users only see the brands and players they’re allowed to see. Module APIs aren’t exposed to the internet at all.
At the edge we have rate limiting and bot protection. We regularly see automated login and bonus-abuse attempts, and most never get past the edge. Partners mostly complain when every endpoint has its own rules, so we keep one scheme and document it well.

How does API-first architecture affect platform scalability and performance, particularly during major sporting events or other periods when large numbers of services may be making simultaneous calls into the platform?

Our biggest peak was not an event. Big events can be planned for. It was an unexpected consequence of good marketing. It is hard to plan or test what will happen, as you don’t know if it will get viral and how players will react. An example was a daily reset of a bonus prize. The reset was done at an exact hour of the day, so player activity was confined into a few minutes interval, and we were overwhelmed at first. Some of the functionalities were not optimised, as we didn’t expect them to be used so heavily. After we optimised them, the problem went away.

The architecture helps a lot with spikes like that. Most of the load is reads, and those we serve from cache and read replicas, away from the core. Modules like promotions run separately from betting and the wallet, and the event bus and rate limiting take care of the rest.

Before every release we still run multi-hour load tests against each operator’s real traffic profile. The move to Kubernetes will make it easier to scale individual services, and we’re looking at Kafka for event streaming at higher volumes.

As operators increasingly want the freedom to select individual components of their stack, do you expect the role of the platform provider to change from supplying a largely self-contained technology ecosystem to providing the orchestration layer that holds a more modular ecosystem together?

Yes, there are some enterprise sized companies that were merging or buying different systems. I and some others were involved in company and government orchestrations before, so it felt more like integrator project than platform provider. We also had to store and serve some data that we don’t need from the platform perspective but it is needed to connect to all different internal integrations. It was opportunity for us to share some old stories with the team. Operators will keep choosing their own front end, CRM, data tools and specialist suppliers.

What they still need from the platform is a core they can trust. Our clients already range from “just give me the API” to “run the whole portal for us”, so we’ve had to be both a complete platform and a set of building blocks.