Switching aggregators

This is the engineering half of the move. If the decision itself is still open, whether the economics hold at your volume and how a switch runs without a cutover date, start at Switch to Aggregator.gg and come back here with your integrator.

You have run an aggregator integration before: a wallet endpoint, signed callbacks, an error dictionary, a go-live gate. This page translates that experience into this platform’s terms, shows a migration shape that never takes your current supply down, and answers the questions experienced teams ask before writing any code. Nothing here is new machinery: every cell links into the contract pages that define it.

What maps to what

Your existing integration has a shape. Here is where each piece lands on this platform:

You run today	Here it becomes
Sandbox keys, test tiers, environment promotion	One agg_ key and one production environment. Before a wallet test, confirm access, available credits and spending limits; welcome credits may help if present, and demo sessions launch games with no wallet involved. There is no promotion step because there is nothing to promote between.
Your aggregator’s callback schema	One callback contract for every provider: bet, win, and refund on a single endpoint, amounts as integers in the currency’s minor units, and a response carrying the new balance. Whichever studio originates the event, the payload shape is the same.
Timestamped signature headers	X-SIGNATURE: a lowercase hex HMAC-SHA256 of the raw request body, keyed with your callback_secret. No prefix, no timestamp parameter, no scheme marker. Replay defence uses persistent trusted integration/organization + provider + transaction identity, rather than a signature timestamp.
Decline and duplicate conventions	Use the exact callback response classifier: valid HTTP 200 confirms settlement, recognized 402 declines, eligible 5xx/transport failures have bounded retries, and malformed 200 or other 2xx leave delivery unknown without automatic redelivery. Replay a duplicate scoped identity’s original status and body. Exhausted or unsafe delivery requires investigation; universal manual replay is not promised.
Idempotency conventions on outbound calls	The Idempotency-Key header is required on the two money-touching POSTs, /v1/sessions and /v1/free-rounds. Sessions replay the original status/body with X-Idempotent-Replayed: true from a 24-hour completed-response cache; grants use durable results and a body _replayed marker. The two endpoints answer key reuse differently, and the page is explicit about how.
Your current error dictionary	One envelope with stable machine codes and a complete reference grouped by family, each code with its HTTP status and the action it asks of you. Handle endpoint-specific flat errors, pacing and ambiguous outcomes as well as named codes.
Rate-limit folklore	Deployed numbers: 600 requests a minute per key, 3000 per issuing user across that user’s keys, fixed 60-second windows, X-RateLimit-* headers where propagated, and a limiter that fails closed instead of admitting unmetered traffic.
Per-studio catalogs and bonus tools	One catalog across studios with RTP, volatility, and country metadata on every game, and free rounds that settle through the callback endpoint you already built: is_free: true on the same payload, no separate endpoint.
Multi-brand setups	Platform accounts: platform credentials selecting existing brands through supported sub_operator_ref fields, per-brand catalogs/attribution and a shared parent wallet. Create the first brand before the quickstart.

Migrating without downtime

The integration is additive: nothing in it requires touching the supply you run today.

1. Stand up a second wallet endpoint. The callback endpoint for this platform is new code at a new URL with its own callback_secret; your existing integration keeps running untouched next to it. Implementation includes durable atomic settlement, trusted player/session context and provider-specific recovery. Plan the migration around that work and your review process.
2. Prove the money path within an agreed test budget. Confirm access and credits before the human runs real sessions, signed callbacks and settlement. The six-step track is the skeleton: each step ends with a check you can run, and the final step reconciles your ledger against GET /v1/transactions.
3. Hold the new path to the go-live checklist. Go-live is the parity gate: money handling, security, and operations checks, with evidence for your own integration. When the checklist closes, open real traffic at whatever pace your lobby allows: per game, per player segment, or all at once. How you route players between supplies stays your storefront’s decision.

Nothing here obliges a cutover date. Both integrations can serve traffic side by side for as long as the comparison is useful to you.

Questions migrating teams ask

Will the contract change under my integration?

The commitment is compatibility: the callback shape and API surface documented on this hub are what runs in production, and integrations built against them are expected to keep working. Error codes are stable by contract: match on code, never on message. A written versioning policy naming change classes and notice windows is in work; until it is published, this hub does not promise dates, and does not pretend a policy exists before it does.

Where is the sandbox?

New operator onboarding has no public test-key tier. One environment, one agg_ key: controlled tests with confirmed access and budget exercise the real money path, demo sessions cover UI checks, without implying that a synthetic test covers every production condition. Legacy credentials and provider staging have their own boundaries.

How do I rotate an API key?

By overlap, not by a rotation button; the current mechanics live on API keys. Keys do not expire, and the cap is 10 non-revoked keys per issuing user, so you rotate when you choose: create a named replacement, deploy it, watch the old key’s Last used timestamp go quiet, and revoke it.

Is there an SLA?

The public Operator Service Offer includes Schedule B, with routing-layer objectives and exclusions. Read the applicable terms; the status page is operational evidence, not a substitute for them. Also public: the status page with uptime and incident history, no account required, and error semantics that split retryable platform failures from terminal request errors, so your alerting can tell one from the other.

How big is the catalog?

These docs do not print a number, deliberately: a printed count would be stale by the time you read it. The live answer is one call under your key, GET /v1/games, with filters for type, volatility, RTP, features, and currency. And a key is not far away: creating one is self-serve, and KYB verification is not a technical precondition for minting it.

Can I generate a client from the spec?

Yes. The API Reference on this hub is generated from the OpenAPI document published at /openapi.yaml, and the published file is byte-identical to the spec the reference pages are built from, so a generated client and the reference can never disagree. Download it and point your generator at it.

Can an AI agent do the legwork?

That surface is built on purpose. llms.txt and llms-full.txt carry the approved documentation as a machine-readable corpus, the hosted MCP server exposes the catalog and integration state as typed tools under your own key, and Agent guidelines draws the boundary between what an agent can prove alone and where a human signs off. Teams pointing an agent at a migration start with those three pages.

When you are ready for the contract itself, start at Callbacks: if you build one page of this integration carefully, build that one.