The question of which APIs to integrate is usually asked too late, and it is usually the wrong question. The useful one comes first: where does the boundary run between your content platform and your gaming platform, and which system owns what.
Get that wrong and the integration list does not matter, because you will be integrating the right services into the wrong architecture.
Short answer. WordPress owns presentation, content and acquisition. A certified platform owns the player account, the wallet, the game session and bet settlement. The integrations that matter are the few that sit on the line between them, and there are fewer of them than most vendor lists suggest.
Where the boundary runs
Three layers, and the middle one is where the work is.
| Layer | Owner | What lives there |
|---|---|---|
| Presentation and content | WordPress | Landing pages, SEO, promotion terms, help centre, per-market variants, affiliate pages |
| Integration | Custom code | Session handoff, game catalogue, jurisdiction gating, personalised fragments |
| Transactional core | Platform (PAM) | Player account, wallet, game session, bet settlement, KYC, payments, audit trail |
One rule governs the whole design. WordPress is never the system of record for money or identity. It can display a balance. It cannot hold one.
This is not a limitation of the platform. It follows from what regulators require of the transactional layer: certification, transaction integrity and an audit trail that survives inspection. We set out those requirements in more detail in our guide to iGaming licensing.
What actually sits in WordPress
Four integrations. Everything else is either content or somebody else’s system.
Session handoff
The most important one and the most common source of trouble. A player logged in on the platform has to be recognised on the content site, and the two systems have to agree on who that player is without WordPress ever storing a credential.
Mature platforms expose an OpenID Connect endpoint, which makes this a configuration task. Less mature ones expose a signed token endpoint, which makes it a development task. A few expose neither, and the answer to that is to establish it during vendor selection rather than after.
What WordPress holds is a session reference and a set of display attributes: segment, market, verification status, whether the player is self-excluded. What it does not hold is the password, the balance, or anything a regulator would want to audit.
Game catalogue as metadata
The catalogue splits cleanly, and treating it as one thing is a frequent mistake.
Game metadata is content. Name, provider, thumbnail, RTP, volatility, categories, device support, and availability per market. That belongs in WordPress, because it is what search engines read, what your editors curate, and what your landing pages are built from.
Game launch is not content. The launch token, the session and the wallet calls belong to the platform. WordPress renders a link. It does not open a session.
The catalogue should synchronise from the aggregator or platform API on a schedule, not be maintained by hand. Manually maintained catalogues drift, and the drift shows up as a player clicking a game that is not available in their market.
Jurisdiction gating
Geolocation determines what a visitor may be shown, and that is genuinely a presentation-layer concern. Which pages, which terms and conditions, which licence details in the footer, which payment method logos, which responsible gambling messaging, which games appear in the catalogue at all.
The geolocation check itself may come from a specialist provider or from the platform. Either way, the decision about what to render belongs to the content layer, and it needs to be a first-class part of the template logic rather than a plugin bolted on at the end.
Content operations and personalisation
Promotion terms, bonus rules as published text, help centre articles, market-specific compliance pages. All content, all WordPress.
One detail worth building deliberately. Regulators may ask which version of a promotion’s terms applied on a given date. WordPress can hold the published version history. The platform records which version a specific player accepted. The two are joined by a version identifier that has to be designed in, because nobody adds it retroactively without a migration.
What does not belong in WordPress
Payments. Player wallets. KYC and AML checks. Game session state. Bet placement and settlement. Self-exclusion register checks against national schemes such as GAMSTOP, Spelpaus, OASIS or CRUKS. The transaction audit trail.
The reason is not that WordPress could not technically be made to do these things. It is that the resulting system would have to be certified, audited and maintained to a standard that a content management system is not designed to meet, and that the certification would have to be repeated for every market you enter.
Where we see this go wrong, it is rarely a deliberate decision. It starts with one convenient shortcut, usually storing a player attribute in WordPress because the platform API was slow that week.
Five ways these integrations break
From projects rather than from theory.
Player data in wp_usermeta. The moment a player attribute is written to WordPress and also exists on the platform, you have two sources of truth. They agree until they do not, and the disagreement surfaces in a support ticket about a bonus that vanished.
A cached page showing a balance. Full-page caching and player context are incompatible unless the boundary is explicit. Personalised fragments have to load outside the cache, either client-side or through edge-side includes. This is the failure that produces the worst incidents, because one player briefly sees another player’s state.
Bonus logic duplicated in the content layer. A promotion rule implemented in WordPress to avoid waiting for a platform release will diverge from the platform’s rule within weeks. The player then sees one thing and is credited another.
No defined behaviour when the platform API is unavailable. Every platform has downtime. The question is whether your site degrades to content mode with a cached catalogue and hidden personalised blocks, or returns a server error to every visitor including the ones who only wanted to read a review.
Player-context calls on every page render. Player endpoints are rate limited, and campaign traffic arrives in spikes. A template that calls the platform on every request will hit the limit at exactly the moment it matters.
What to ask your platform provider
These questions decide how much integration work you are buying. Ask them before signing, not after.
Does the platform expose an OpenID Connect endpoint for session handoff, or do we build a token exchange?
Is the game catalogue available as an API, and does it carry availability per market and per device?
What are the rate limits and expected latency on player-context endpoints?
Who owns the bonus rules engine, and can the content layer read bonus state without reimplementing the logic?
Is there a sandbox with a representative catalogue and test players, or only production?
Is there a documented status endpoint we can use to trigger graceful degradation?
Which certifications does the platform hold for each market we target, and do they constrain what we may render on our own pages?
A provider who answers these clearly is one you can plan against. A provider who cannot is a schedule risk you have not costed yet.
FAQ: iGaming APIs
Can WordPress handle player accounts?
It should not. Player accounts, wallets and bet settlement sit in the certified platform, because that is the layer regulators audit. WordPress holds a session reference and display attributes.
Do we need a headless setup for this?
Not necessarily. A conventional WordPress site can consume platform APIs perfectly well. Headless is worth it when you have permanent front-end capacity and a genuine multi-channel requirement, not as a way to solve an integration problem.
Can we display a live balance on the content site?
Yes, provided the cache boundary is explicit. The balance fragment loads outside the full-page cache and reads from the platform. It is never stored in WordPress.
Single wallet or transfer wallet?
This is a platform-level decision, not a WordPress one. Most current integrations use the single-wallet model, known in the industry as a seamless wallet, where the game provider calls the operator’s wallet in real time. Either way, the content layer is unaffected.
Who is responsible for AI Act transparency on our chatbot?
It depends on who the provider is. If you licence the chatbot, the vendor carries the obligation. If it ships under your brand, it is probably yours. Article 50 has applied since 2 August 2026, and we cover the distinction in our article on the EU AI Act for iGaming platforms.
How long does this integration usually take?
The variable is the platform, not WordPress. Where an OpenID Connect endpoint and a documented catalogue API exist, the work is measured in weeks. Where they do not, most of the effort goes into building what the platform should have exposed.
In summary
The list of APIs matters less than the line they sit on. Content, catalogue metadata, jurisdiction logic and session handoff belong to WordPress. Money, identity and game state belong to the platform. Projects that hold that line integrate quickly and pass audits. Projects that blur it spend their second year reconciling two sources of truth.
We build the content and integration layer for operators who already have a platform, and we tell you where the line should sit before anyone writes code. See how we work with iGaming operators, or talk to us about your current setup.
