How does PlayerLoop connect to our platform?

Event ingestion over Kafka, APIs or webhooks, whatever your platform emits. Actions flow back through your existing APIs, so rewards land in player accounts natively.

How long does integration take?

The first external casino, with around 45 Kafka topics and an encrypted feed, was connected and ingesting three months of history in one day. Typical integrations are measured in days.

Is our data isolated?

Each casino is an isolated tenant with its own process, database and feed adapter. Nothing is shared across operators.

Do we need to change our event schema?

No. A per-tenant feed adapter maps your events into PlayerLoop’s typed models, so very different platforms onboard without platform changes.

Developers

Events in. Actions out. Everything typed and audited.

PlayerLoop consumes your platform’s event feed, builds a per-player data engine on top, and executes actions back through your existing APIs. Here’s how it fits your stack.

Ingestion

Your event stream, whatever shape it's in.

Kafka with encrypted payloads, REST APIs, webhooks or database feeds. One adapter per casino, tuned to your platform.

Kafka-native

mTLS consumer groups against your existing brokers. Encrypted payloads are supported, with AES-GCM decryption at the edge of our stack.

APIs & webhooks

No Kafka? Poll-based ingestion, push webhooks or direct database feeds through a custom adapter.

Never lose an event

Raw events are stored before processing. A failed typed insert dead-letters and retries. It never blocks the stream or drops data.

Typed models on raw data

Every event lands raw, then materializes into typed tables: bets, wins, transactions, sessions. Your reporting starts from clean schemas.

Inbound event

{
  "type": "DEPOSIT",
  "playerId": "8841",
  "amount": "250.00",
  "currency": "USD",
  "eventTime": "2026-07-29T22:41:31Z"
}

Outbound action

POST /api/rewards/issue
{
  "playerId": "8841",
  "reward": { "type": "free_spins", "count": 40 },
  "reason": "mission_completed:3-game-explorer",
  "idempotencyKey": "msn-9034-2026-07-29",
  "budget": "missions-weekly"
}

Architecture

Isolated by tenant. Boring by design.

The parts that touch money and player data are deliberately unexciting: isolated deployments, idempotent writes, audit everywhere.

One deployment per casino

Own process, own Postgres database, own feed adapter. Tenants share code, never data or runtime.

Platform-agnostic

Every casino platform is different. Feed adapters are self-contained per tenant, so your platform quirks stay yours.

Actions through your APIs

Bonuses, payouts and player messages execute through your existing backoffice and bonus APIs, with idempotency keys on every financial action.

Security by construction

API-key auth between services, role-based permissions in the console, encrypted feeds, full audit logs on every automated action.

Live event stream

22:41:03PLAYER_LOGINplayer #1187
22:41:19BETplayer #8841 · $12.50 · slots
22:41:31DEPOSITplayer #2210 · $250
22:41:44WINplayer #8841 · $86.00
22:42:02CHURN_RISKplayer #5177 · score 0.87
22:42:15MISSION_COMPLETEDplayer #9034 · 3-game explorer

Integration timeline

The first external casino was connected in one day: credentials in the morning, 45 Kafka topics consuming by the afternoon, three months of historical events backfilling overnight. Your platform will differ, and the adapter pattern is built for exactly that.

Frequently asked questions

: Event ingestion over Kafka, APIs or webhooks, whatever your platform emits. Actions flow back through your existing APIs, so rewards land in player accounts natively.
: The first external casino, with around 45 Kafka topics and an encrypted feed, was connected and ingesting three months of history in one day. Typical integrations are measured in days.
: Each casino is an isolated tenant with its own process, database and feed adapter. Nothing is shared across operators.
: No. A per-tenant feed adapter maps your events into PlayerLoop’s typed models, so very different platforms onboard without platform changes.

Talk to the people who built it.

Bring your CTO. We'll bring the architecture diagrams.

See It in Action See the platform