Platforms

A platform runs casino infrastructure for several brands at once: white-label operators, a multi-brand group, a casino-management provider. In Aggregator.gg’s model you are one customer with one integration, and your brands live beneath your account as attribution. This page is the orientation; the mechanics live on Platform accounts.

The business model

A platform uses the operator wallet protocol with an additional brand model. You hold one contract and shared credit balance; every brand you serve is a sub-operator beneath that account. Brands do not hold balances, do not log in, and are not parties to your agreement: you are the customer, and the brands are how your traffic is broken down.

Billing follows the same shape. Every brand’s spins draw down the platform’s balance, funded by prepaid spin packages, with one top-up flow and one invoice however many brands you run, broken down by brand in the attribution. The money path itself is the operator contract: wallet callbacks signed with HMAC, amounts as integers in minor units, confirmed access and budget required for your first controlled rounds.

What you can use today

The currently supported brand layer includes:

• Brand attribution on supported calls: sub_operator_ref names which brand a session, catalog read, or free-rounds call acts as, and that brand’s spins are counted as its own in sessions, transactions, and analytics.
• Per-brand catalogs: providers and titles are enabled per brand, so two brands under your key can legitimately show different games.
• Brand creation, explicit or on first use: POST /v1/sub-operators ahead of traffic, or auto-provisioning on the first call that names a new ref.
• A default brand: the first brand becomes the default; omitted refs can select it when active and strict mode is off. Send refs explicitly to avoid attribution mistakes.
• Strict mode: require_sub_operator_ref on your account makes a missing ref fail loudly instead of landing on the default, worth enabling once “attributed to the default” would be a silent accounting problem.
• A shared platform wallet: brand callbacks use the parent platform’s URL and secret. Independent brand overrides are not a supported production contract, and platform setup can require support.

How you integrate

Start by creating a brand and confirming its provider access and catalog. Then follow the six-step Getting started wallet integration with sub_operator_ref on the supported operations. A platform without an active default cannot first launch as an ordinary operator and add brands later: omitted refs can fail with E6010 or, in strict mode, E6005.

Confirm the shared callback configuration before money tests. Keep the session-to-brand mapping in your backend and arrange brand-level reconciliation: the current GET /v1/transactions endpoint is scoped to the authenticated identity and does not accept a brand selector.

Where to start

Read Platform accounts for brand creation, endpoint-specific selectors, provisioning limits and the shared wallet. Use Getting started for the common wallet contract, with human-controlled tests, payment and launch.