Skip to content
The Aggregator

Environments & testing

Before testing, confirm the deployment and organization authorized for your integration, the enabled providers and games, your callback setup, and any agreed funding or welcome credits. Registration and possession of a key do not establish these prerequisites or go-live approval.

Use the credential issued for that integration unchanged. Key format, permissions and lifecycle follow the deployed policy; see Authentication.

Production base URL

Section titled “Production base URL”
https://api.aggregator.gg/v1

The examples use this production URL. Use it only with access authorized for production. Provider/session diagnostics and internal staging validation are separate; an example does not convert a credential or authorize another deployment.

Platform IP addresses

Section titled “Platform IP addresses”

When the platform calls out to your systems — forwarding bet / win wallet callbacks to your callback URL, or (for game providers) calling your game/RGS API — the request originates from a fixed set of platform egress IPs. If you firewall or IP-allowlist the endpoint that receives our traffic, add these addresses so requests are not blocked.

Environment Egress IP (IPv4)
Production 116.202.36.242
Staging 46.224.211.29
  • Operators integrate against production only — allowlist the Production IP on the endpoint that receives wallet callbacks.
  • Game providers validate against staging before go-live — allowlist both the staging and production IPs on the systems the platform calls.

All platform egress is IPv4 today. These addresses are stable, but can change with infrastructure migrations; material changes are announced in advance via the changelog and direct notice. HMAC signature verification remains mandatory regardless of source IP — the allowlist is an additional network control, never a replacement for verifying the signature.

Funding and welcome credits

Section titled “Funding and welcome credits”

If welcome credits are part of your launch agreement, confirm that they have been enabled and understand their amount, permitted use and replenishment terms before running real sessions. These docs do not promise automatic credits for registration.

Real-session validation can move wallet funds. Configure and verify wallet callbacks first, use an authorized test player, and reconcile the resulting transactions. An API key alone does not complete provider setup, funding or launch approval.

Demo previews

Section titled “Demo previews”

Where the provider supports it, POST /v1/demo-sessions launches a preview without wallet involvement. Demo sessions do not debit a wallet or emit bet/win callbacks, so they do not validate settlement, callback delivery or real-session availability.

Validation practices

Section titled “Validation practices”
  • Verify signatures and persist each wallet operation’s idempotent result before returning success.
  • Confirm that duplicate callbacks replay that stored result without another wallet movement.
  • Reconcile against the transactions API before opening customer traffic.
  • Complete the Go-live checklist and applicable launch requirements independently of any demo or advisory check.

Rate limits

Section titled “Rate limits”

Respect the response’s supplied Retry-After and rate-limit headers. Confirm capacity and the policy applicable to your integration; these docs do not guarantee particular numeric defaults or independent read/write budgets. See Authentication.

Section titled “Read next”